From davidalayachew at gmail.com  Mon Jan  1 06:26:25 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 1 Jan 2024 01:26:25 -0500
Subject: New method on java.util.function.Function -- ternary method
In-Reply-To: <CAA9v-_M2sovP7TQE2HcWYP=v++F-Wo2NRQiGa36do1dtveMwRg@mail.gmail.com>
References: <CAA9v-_OO2EkG_oS3YTFQi85e04pnfJKHnzfAi0XbHv91n7Uu7w@mail.gmail.com>
 <CAA9v-_PQuWYCxJ1Tz7veJm9xFxJ6tqvx9avTBxU6DR3xOAGckw@mail.gmail.com>
 <CAA9v-_ObOe-buDL=SN-q36VOBrNNp1o-UPtG5gXAkZXb8Saryg@mail.gmail.com>
 <CAA9v-_M2sovP7TQE2HcWYP=v++F-Wo2NRQiGa36do1dtveMwRg@mail.gmail.com>
Message-ID: <CAA9v-_N3yUR+QPic3vjAtsbj3SkxaW4svhXP93xxtfB+yU+W4g@mail.gmail.com>

Hello all,

After reading through Brian Goetz's "Effect cases on Switch" (specifically,
the "Other switch tricks" section), I have decided to not implement this
feature after all. The fact is, switch expressions, especially with
"when-clauses", does a better job of clarifying intent than this feature
does. Sure, there is slightly more verbosity, but the intent of this
feature was never to minimize the character count, it was to increase
clarity. And as is, switch expressions with when clauses accomplish that
better.

Here is a link to the subsection of the abovementioned article --
https://inside.java/2023/12/15/switch-case-effect/#other-switch-tricks

Could someone help me close this on JBS? Or should it just not be closed at
all?

Here is a link to the JBS -- https://bugs.openjdk.org/browse/JDK-8319802

Thank you for your time and help!
David Alayachew

On Thu, Nov 9, 2023 at 1:19?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Oh, I will also add a specialized version of this method to
> java.util.function.UnaryOperator. That is because UnaryOperator is a
> subinterface of Function. Function goes T -> R, but UnaryOperator just goes
> T -> T. We do not want UnaryOperator to have the T -> R static function
> included due to inheritance, so it will get its own version that has the
> same method name and parameters, but the type parameters will be different.
>
> Here is another mockup - this time for UnaryOperator2's version of the
> same method.
>
> > interface UnaryOperator2<T> extends Function2<T,T>, UnaryOperator<T>
> > {
> >
> >     public static <T> UnaryOperator2<T> ternaryApply
> >     (
> >         Predicate<? super T> test,
> >         Function<? super T, ? extends T> trueFunction,
> >         Function<? super T, ? extends T> falseFunction
> >     )
> >     {
> >
> >         return
> >             (T input) ->
> >                 test.test(input)
> >                     ? trueFunction.apply(input)
> >                     : falseFunction.apply(input)
> >                     ;
> >
> >     }
> >
> > }
>
> On Thu, Nov 9, 2023 at 12:12?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> It has been a month since I sent this proposal. Since no one has told me
>> that this is a terrible idea, I will submit this as an enhancement to JBS,
>> and once the ticket is made, start work on creating a pull request.
>>
>> On Tue, Oct 3, 2023 at 3:13?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Whoops, bad import.
>>>
>>> Please replace the following line with the one after it.
>>>
>>> > import java.util.function.Function;
>>>
>>> > import java.util.function.*;
>>>
>>> On Tue, Oct 3, 2023 at 3:09?AM David Alayachew <davidalayachew at gmail.com>
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I have an idea that I want to run by you all -- a new method on
>>>> java.util.function.Function to capture ternary operations.
>>>>
>>>> Here is a mockup of what I wanted to do.
>>>>
>>>> >
>>>> > import java.util.function.Function;
>>>> >
>>>> > @FunctionalInterface
>>>> > public interface Function2<I, O> extends Function<I, O>
>>>> > {
>>>> >
>>>> >    public static <I, O> Function<I, O> ternary
>>>> >    (
>>>> >        Predicate<I> test,
>>>> >        Function<I, O> trueOutput,
>>>> >        Function<I, O> falseOutput
>>>> >    )
>>>> >    {
>>>> >
>>>> >       return
>>>> >           (I input) ->
>>>> >               test.test(input)
>>>> >               ? trueOutput.apply(input)
>>>> >               : falseOutput.apply(input)
>>>> >               ;
>>>> >
>>>> >    }
>>>> >
>>>> > }
>>>> >
>>>>
>>>> I think this is useful for a few reasons.
>>>>
>>>>  * This composes, just like the ternary operator itself.
>>>>
>>>>  * It pairs well with Function.identity() and method references to
>>>> clearly (but concisely) communicate intent.
>>>>
>>>>  * Ternary operations are common, so this will find great use by
>>>> developers of all sorts.
>>>>
>>>> There is at least one part I don't quite like about this design - what
>>>> if one (or both!) of your outputs is not a functional transformation of the
>>>> input?
>>>>
>>>> For example, String username = id.isBlank() ? "UNKNOWN" : lookup(id);
>>>>
>>>> Obviously, this is easy to work around - simply ignore the input of the
>>>> function. But you lose clarity and simplicity that way. I would put a note
>>>> in the javadoc that says that this method should only be used in instances
>>>> where both outputs are a functional transformation of the input. That way,
>>>> intent is clarified. But if we go that route, maybe this function should
>>>> get a better name to capture that? testThenApply? ternaryTransform?
>>>> ternaryApply?
>>>>
>>>> Thank you for your time and help!
>>>> David Alayachew
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240101/c3e97387/attachment-0001.htm>

From alanb at openjdk.org  Mon Jan  1 08:37:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Jan 2024 08:37:48 GMT
Subject: RFR: 7009069: ZipFile.getEntry(String name) does NOT respect the
 "language encoding flag" [v2]
In-Reply-To: <4caeCYPWKG4cFAcP9w9rHe1v6n9iU3nt_vvP6s4JmlQ=.996311a7-5df0-4e28-b9d6-ecde61a73559@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <4caeCYPWKG4cFAcP9w9rHe1v6n9iU3nt_vvP6s4JmlQ=.996311a7-5df0-4e28-b9d6-ecde61a73559@github.com>
Message-ID: <aCEp0a4B8DFcrK8N0fcEij-02cONmBPytsK3kXuecVo=.83a35f36-4067-469d-9f8c-c84bcf63632e@github.com>

On Sun, 31 Dec 2023 23:25:51 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.
>
> 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.

It's great to improve the test coverage in this area but I'm sure about re-purposing JDK-7009069 to do this. Consider a future archaeologist looking through the commits where it initially looks this might be a fix to ZipFile to respect the language encoding flag. So I think create a new issue for the test work or else change the title on this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/17207#issuecomment-1873225058

From eirbjo at openjdk.org  Mon Jan  1 14:13:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 1 Jan 2024 14:13:50 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v2]
In-Reply-To: <aCEp0a4B8DFcrK8N0fcEij-02cONmBPytsK3kXuecVo=.83a35f36-4067-469d-9f8c-c84bcf63632e@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <4caeCYPWKG4cFAcP9w9rHe1v6n9iU3nt_vvP6s4JmlQ=.996311a7-5df0-4e28-b9d6-ecde61a73559@github.com>
 <aCEp0a4B8DFcrK8N0fcEij-02cONmBPytsK3kXuecVo=.83a35f36-4067-469d-9f8c-c84bcf63632e@github.com>
Message-ID: <eweu18qZxcawiHlAMcVQjNhwO37gBYjTfbSE1_1tV88=.97471e61-c3f3-458a-be99-eaa3711ec35a@github.com>

On Mon, 1 Jan 2024 08:35:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So I think create a new issue for the test work or else change the title on this one.

Filed a new issue [JDK-8322802](https://bugs.openjdk.org/browse/JDK-8322802) for tracking this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17207#issuecomment-1873343972

From eirbjo at openjdk.org  Mon Jan  1 14:29:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 1 Jan 2024 14:29:50 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v3]
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: <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@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:

  Add @bug tag for 8322802

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17207/files
  - new: https://git.openjdk.org/jdk/pull/17207/files/3555ec53..310c12a3

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 jbhateja at openjdk.org  Mon Jan  1 14:36:06 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 1 Jan 2024 14:36:06 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
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: <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Accelerating masked sub-word gathers for AVX2 targets, this gives additional 1.5-4x speedups over existing implementation.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
 - Removing JDK-8321648 related changes.
 - 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.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/518ec971...de47076e

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

Changes: https://git.openjdk.org/jdk/pull/16354/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=09
  Stats: 1421 lines in 32 files changed: 1373 ins; 20 del; 28 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 duke at openjdk.org  Mon Jan  1 16:32:45 2024
From: duke at openjdk.org (duke)
Date: Mon, 1 Jan 2024 16:32:45 GMT
Subject: Withdrawn: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig
In-Reply-To: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
Message-ID: <W9DJ6ia6eS59VErG9dvwFaLlSuq3343ACnDfcuLZ2W8=.4d23197f-f86e-428d-8d9d-522d6377a8b9@github.com>

On Mon, 6 Nov 2023 06:41:22 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Mon Jan  1 16:43:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Jan 2024 16:43:48 GMT
Subject: RFR: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig [v2]
In-Reply-To: <Oe3nr5ldhn0dvhgUK80Q-Y1oQqjNY3yFlV_OIUIcAd4=.93bf26b1-e469-42f5-99e7-1eb3a26e6bf1@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
 <Oe3nr5ldhn0dvhgUK80Q-Y1oQqjNY3yFlV_OIUIcAd4=.93bf26b1-e469-42f5-99e7-1eb3a26e6bf1@github.com>
Message-ID: <Y4LTlsIBR0IgJK_Yv-XPkjnVqiWAiijCcFLB0oWXRIQ=.376114aa-4e30-4a38-a5b6-0256d6f7a9fa@github.com>

On Mon, 4 Dec 2023 15:23:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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

This has a conflict with #17058 (8321540) so I plan on fixing conflict after that one is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/16514#issuecomment-1873394758

From eirbjo at openjdk.org  Mon Jan  1 17:07:04 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 1 Jan 2024 17:07:04 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the wrapped
 stream
Message-ID: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>

Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream.

Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.

This fix is to move the closing of the wrapped stream inside the finally block.

Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*

Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.

Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.

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

Commit messages:
 - Add a sanity check that the wrapped stream is closed for the normal case where the wrapped stream does not throw during flushing
 - Make DeflaterOutputStream.close close its wrapped output stream even if finish() fails

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

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

From duke at openjdk.org  Mon Jan  1 17:24:57 2024
From: duke at openjdk.org (duke)
Date: Mon, 1 Jan 2024 17:24:57 GMT
Subject: Withdrawn: 8316641: VarHandle template classes can share code in the
 base class
In-Reply-To: <AKBd8KmVCUr_J-aImmR3SV3YTRM1JjEm8RKNdNwsjf0=.7363b031-ad71-4ae4-a949-f58a75e28385@github.com>
References: <AKBd8KmVCUr_J-aImmR3SV3YTRM1JjEm8RKNdNwsjf0=.7363b031-ad71-4ae4-a949-f58a75e28385@github.com>
Message-ID: <yhWR6m8KukLRwjytSz1mN3T-h54nTu_1g3IxznDiiI4=.019e84eb-e1a3-4cca-834c-b279212fca9f@github.com>

On Thu, 21 Sep 2023 05:43:20 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.

This pull request has been closed without being integrated.

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

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

From david.holmes at oracle.com  Tue Jan  2 02:07:54 2024
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 2 Jan 2024 12:07:54 +1000
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
Message-ID: <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>

Hi Glavo,

On 24/12/2023 4:18 am, Glavo wrote:
> 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.

AFAICS java.library.path (and sun.boot.library.path) are input 
properties that can be set by the user. There are no "default" values 
for these properties as such. The library loading will ultimately rely 
on the behaviour of dlopen, if no additional paths have been set, so it 
seems to me what you really want is for dlopen to act "the same way" 
that ld does. Note that dlopen will already check the contents of 
/etc/ld.so.cache

> 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?

This does not seem practical. On my system ld.so.conf just contains

include ld.so.conf.d/*.conf

so now we (hotspot) have to read the top-level file, parse it, interpret 
it and then recursively read, parse and interpret more files.

Cheers,
David
----


> Glavo
> 
> [1]: https://wiki.ubuntu.com/MultiarchSpec 
> <https://wiki.ubuntu.com/MultiarchSpec>

From duke at openjdk.org  Tue Jan  2 02:57:08 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jan 2024 02:57:08 GMT
Subject: Withdrawn: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
Message-ID: <Ab4I3ZF4gjqUGA3Wvg1ju9iFSJajQbyeoNYCBDtthX4=.61dab4c5-2126-46f1-b8a5-c17a71e635ec@github.com>

On Sat, 8 May 2021 20:54:48 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

> Sorting:
> 
> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single element
> - minor javadoc and comment changes
> 
> Testing:
> - add new data inputs in tests for sorting
> - add min/max/infinity values to float/double testing
> - add tests for radix sort

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue Jan  2 06:50:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 06:50:47 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: <BXJN2wb4GUwuT7O1aWHochbYoVdbEt2tIxP-C1PXCvo=.9a1fa055-6999-4370-ad55-9b12a5fde132@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.

Hello Archie, the changes look fine to me. I see that Joe has approved this change and the CSR too has been approved. I've triggered a CI run to verify there's no unexpected issues. Once that completes, I'll go ahead and sponsor this.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17090#pullrequestreview-1800002086

From jpai at openjdk.org  Tue Jan  2 07:07:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 07:07:54 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: <aMJjPAD_oDP6l0bIi-iYnm6ngZIefW_nKtAeqIrssQM=.0db96a0a-91de-41a3-8b64-4f752dfde65b@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

Hello Adam, the changes look good to me. Please update the copyright year on ClassReaderImpl.java. I have a couple of comments which I've added inline.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 200:

> 198:         try {
> 199:             return buffer[p] & 0xFF;
> 200:         } catch (IndexOutOfBoundsException e) {

This and all other catch blocks introduced in this change can be changed to the specific exception type `ArrayIndexOutOfBoundsException`, because all these operations are dealing with only array access. If you prefer catching this more generic `IndexOutOfBoundsException`, that's fine with me.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 283:

> 281:     public void copyBytesTo(BufWriter buf, int p, int len) {
> 282:         try {
> 283:             buf.writeBytes(buffer, p, len);

`java.lang.classfile.BufWriter` doesn't specify any `@throws` for its `writeXXX` methods. Should it be specified (of course in a separate PR)?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16762#pullrequestreview-1800010401
PR Review Comment: https://git.openjdk.org/jdk/pull/16762#discussion_r1439194339
PR Review Comment: https://git.openjdk.org/jdk/pull/16762#discussion_r1439194853

From jpai at openjdk.org  Tue Jan  2 07:20:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 07:20:37 GMT
Subject: RFR: 8321540: ClassSignature.parseFrom() throws
 StringIndexOutOfBoundsException for invalid signatures
In-Reply-To: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
References: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
Message-ID: <3vf7u7QrIbZdJfpn_9rvBmbFGMfrnNzztntf2usCLK8=.f347e084-dd9c-41e0-9f38-2f14291951c7@github.com>

On Mon, 11 Dec 2023 15:17:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 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

Hello Adam, these changes look fine to me. Please update the copyright year on `SignaturesImpl.java` before integrating.

I'm guessing you have intentionally not included the original `IndexOutOfBoundsException` as a cause in the `IllegalArgumentException` that gets thrown.

Also, it appears that the `SignaturesImpl` is more like an utility class and isn't expected to be used in multi-thread access and thus the reliance on the (non final) instance field `sig` appears OK.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17058#pullrequestreview-1800020682

From jpai at openjdk.org  Tue Jan  2 07:45:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 07:45:48 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v3]
In-Reply-To: <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@github.com>
Message-ID: <4xDVxSkjcop_8IPaol2Quu20YFsS-CmI0XkJXC9K57I=.235eb43f-c847-479a-9610-eaccfd0f7f8a@github.com>

On Mon, 1 Jan 2024 14:29:50 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.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @bug tag for 8322802

test/jdk/java/util/zip/ZipCoding.java line 86:

> 84:                 // ZipOutputStream sets the 'Language encoding flag' when writing using UTF-8
> 85:                 // UTF-8 should be used for decoding, even when opening with a different charset
> 86:                 Arguments.of("utf-8", "iso-8859-1",

Hello Eirik, there are 3 streams of arguments above which use "utf-8" for writing out the entry. All those other 3 streams of arguments, use "utf-8" for reading too (which is OK). For each of those 3 streams of arguments, could you also add another argument stream which uses non-utf8 charset for reading, like you do here? I think that would give this a bit more coverage, especially for cases like the surrogates in comments and entry names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17207#discussion_r1439211686

From jpai at openjdk.org  Tue Jan  2 08:05:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 08:05:47 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v3]
In-Reply-To: <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@github.com>
Message-ID: <KsmSIB_jPnLXxW0zPXlyqHKKs7Ow6JWCXFYv6Nw-fNs=.c03009e2-ca18-4d9e-9c37-584126391e4d@github.com>

On Mon, 1 Jan 2024 14:29:50 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.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @bug tag for 8322802

This is a test-only change PR and the changes being proposed look good to me.

On a general note - I hadn't paid attention to this ZipFile constructor which accepts a character encoding, before. I read up on the Zip file specific today (https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) to understand it a bit more. Interestingly, in that spec (if I read it correctly), unless the `0x0008` "extended language encoding" header is set, there isn't anything that says/allows the entry name or entry comment to be anything other than either UTF-8 or "IBM Code Page 437" character encoding:


APPENDIX D - Language Encoding (EFS)
------------------------------------

D.1 The ZIP format has historically supported only the original IBM PC character 
encoding set, commonly referred to as IBM Code Page 437.  This limits storing 
file name characters to only those within the original MS-DOS range of values 
and does not properly support file names in other character encodings, or 
languages. To address this limitation, this specification will support the 
following change. 

D.2 If general purpose bit 11 is unset, the file name and comment SHOULD conform 
to the original ZIP character encoding.  If general purpose bit 11 is set, the 
filename and comment MUST support The Unicode Standard, Version 4.1.0 or 
greater using the character encoding form defined by the UTF-8 storage 
specification.  ....
....

D.3 Applications MAY choose to supplement this file name storage through the use 
of the 0x0008 Extra Field.  Storage for this optional field is currently 
undefined, however it will be used to allow storing extended information 
on source or target encoding that MAY further assist applications with file 
name, or file content encoding tasks.  Please contact PKWARE with any
requirements on how this field SHOULD be used.

D.4 The 0x0008 Extra Field storage MAY be used with either setting for general 
purpose bit 11.  Examples of the intended usage for this field is to store 
whether "modified-UTF-8" (JAVA) is used, or UTF-8-MAC.  Similarly, other 
commonly used character encoding (code page) designations can be indicated 
through this field.  Formalized values for use of the 0x0008 record remain 
undefined at this time.  The definition for the layout of the 0x0008 field
will be published when available.  Use of the 0x0008 Extra Field provides
for storing data within a ZIP file in an encoding other than IBM Code
Page 437 or UTF-8.


The change to allow user/application specific arbritary charsets to the `ZipFile` constructor seems to have been done long back in Java 1.7 days as part of https://bugs.openjdk.org/browse/JDK-4244499.

This is merely an observation and I don't expect any changes to the ZipFile source or any of your proposed tests, in this context.

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

PR Comment: https://git.openjdk.org/jdk/pull/17207#issuecomment-1873711203

From jpai at openjdk.org  Tue Jan  2 08:40:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 08:40:46 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream
In-Reply-To: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
Message-ID: <7Qt05F3EAkeR_0RtP_nG8edbLcLDwD64BjPaqlr5rEc=.8e985525-e75d-44bc-8ee8-b5df44e01987@github.com>

On Mon, 1 Jan 2024 16:12:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Specification: This change brings the implementation of DeflaterOutputStream.close() in line with its specification: Writes remaining compressed data to the output stream and closes the underlying stream.

> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.

I think this won't require a CSR since the change is merely fixing an issue and making it comply with the specification.

src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 249:

> 247:                     def.end();
> 248:                 }
> 249:                 out.close();

This call has a potential to throw an `IOException` in which case any original `IOException` thrown from the `finish()` call will be lost.

Perhaps we should do something like:


public void close() throws IOException {
        if (!closed) {
            IOException finishFailure = null;
            try {
                finish();
            } catch (IOException ioe){
                finishFailure = ioe;
            } finally {
                if (usesDefaultDeflater) {
                    def.end();
                }
                try {
                    out.close();
                } catch (IOException ioe) {
                    if (finishFailure != null) {
                        ioe.addSuppressed(finishFailure);
                    }
                    throw ioe;
                }
                closed = true;
            }
        }
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/17209#issuecomment-1873737464
PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1439238691

From eirbjo at openjdk.org  Tue Jan  2 09:14:14 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 09:14:14 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v2]
In-Reply-To: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
Message-ID: <DK0AgrnseqxVeLsJ6-Mo64_FscIC0d835kAMiMPt5FI=.a6dda530-2ddf-4c96-993b-b6afe53a3cb8@github.com>

> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream.
> 
> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
> 
> This fix is to move the closing of the wrapped stream inside the finally block.
> 
> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
> 
> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
> 
> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Prevent IOException thrown during finish() from being lost if an IOException is thrown while closing the wrapped stream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17209/files
  - new: https://git.openjdk.org/jdk/pull/17209/files/af21bda7..02707d58

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

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

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

From eirbjo at openjdk.org  Tue Jan  2 09:18:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 09:18:46 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v2]
In-Reply-To: <7Qt05F3EAkeR_0RtP_nG8edbLcLDwD64BjPaqlr5rEc=.8e985525-e75d-44bc-8ee8-b5df44e01987@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <7Qt05F3EAkeR_0RtP_nG8edbLcLDwD64BjPaqlr5rEc=.8e985525-e75d-44bc-8ee8-b5df44e01987@github.com>
Message-ID: <ibEkvC3ZceW4_VYHhLGbb6wpemumPy8bx0UuIpAP23E=.055d5dcf-3853-40fc-bc6e-6d7836a8d8f0@github.com>

On Tue, 2 Jan 2024 08:35:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This call has a potential to throw an `IOException` in which case any original `IOException` thrown from the `finish()` call will be lost.

Good catch. Adopted your suggestion with a few changes:

- The catch for IOException during finish() needs to rethrow the exception
- The catch for IOException during close() needs to check that finishException != ioe, otherwise addSuppressed may throw IAE, see https://bugs.openjdk.org/browse/JDK-8042377
- I renamed finishFailure to finishException

The above changes were inspired by the overridden method `FilterOutputStream.close()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1439265718

From eirbjo at openjdk.org  Tue Jan  2 09:31:16 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 09:31:16 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v4]
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: <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@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:

  Add more cases for 'language encoding' bit set, opened with a different encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17207/files
  - new: https://git.openjdk.org/jdk/pull/17207/files/310c12a3..4f53308c

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

  Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 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  Tue Jan  2 09:31:16 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 09:31:16 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v3]
In-Reply-To: <4xDVxSkjcop_8IPaol2Quu20YFsS-CmI0XkJXC9K57I=.235eb43f-c847-479a-9610-eaccfd0f7f8a@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@github.com>
 <4xDVxSkjcop_8IPaol2Quu20YFsS-CmI0XkJXC9K57I=.235eb43f-c847-479a-9610-eaccfd0f7f8a@github.com>
Message-ID: <qi_yTtvww9zguyG--xcbpf_OnZGphe0xCVUM8pLioHk=.0f25d6d3-693d-4fe1-93ad-20ff255365dc@github.com>

On Tue, 2 Jan 2024 07:43:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @bug tag for 8322802
>
> test/jdk/java/util/zip/ZipCoding.java line 86:
> 
>> 84:                 // ZipOutputStream sets the 'Language encoding flag' when writing using UTF-8
>> 85:                 // UTF-8 should be used for decoding, even when opening with a different charset
>> 86:                 Arguments.of("utf-8", "iso-8859-1",
> 
> Hello Eirik, there are 3 streams of arguments above which use "utf-8" for writing out the entry. All those other 3 streams of arguments, use "utf-8" for reading too (which is OK). For each of those 3 streams of arguments, could you also add another argument stream which uses non-utf8 charset for reading, like you do here? I think that would give this a bit more coverage, especially for cases like the surrogates in comments and entry names.

Thanks, these cases got lost during my parameterization. I've added them back now. 

One such case would probably suffice to verify that the bit flag was interpreted correctly, but it doesn't hurt to have some more variation here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17207#discussion_r1439274478

From eirbjo at openjdk.org  Tue Jan  2 09:37:47 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 09:37:47 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v3]
In-Reply-To: <KsmSIB_jPnLXxW0zPXlyqHKKs7Ow6JWCXFYv6Nw-fNs=.c03009e2-ca18-4d9e-9c37-584126391e4d@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <-teeX1cbAIq-d0VLAVoNY65cAUGQEqGNE9SmqTq8b5M=.817d6df8-bf1a-45d4-a1ba-5c05362c5195@github.com>
 <KsmSIB_jPnLXxW0zPXlyqHKKs7Ow6JWCXFYv6Nw-fNs=.c03009e2-ca18-4d9e-9c37-584126391e4d@github.com>
Message-ID: <f92BNLFAqcFYp5__JtPHMT-u7mQMb0fQtadsSrBNA0w=.78165976-4c6b-47b6-8ce7-e79a25fdda8b@github.com>

On Tue, 2 Jan 2024 08:02:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The change to allow user/application specific arbritary charsets to the `ZipFile` constructor seems to have been done long back in Java 1.7 days as part of https://bugs.openjdk.org/browse/JDK-4244499.
> 
> This is merely an observation and I don't expect any changes to the ZipFile source or any of your proposed tests, in this context.

I agree that changing this long-standing behavior now is probably not worth the risk. Also, there are probably non-compliant ZIPs out there worth opening.

We could perhaps consider adding a note to the documentation of `ZipFile(File, Charset)` mentioning that the only fully standards-compliant charset is 'IBM Code Page 437'. However, I think that's out of scope for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17207#issuecomment-1873790654

From jpai at openjdk.org  Tue Jan  2 10:06:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 10:06:49 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v4]
In-Reply-To: <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
Message-ID: <1pD45oFiJstRxRTAd3hxVMLm6UvzrvGxaOPbvmZipBg=.f151788b-948d-471c-a92f-b7f853348b6f@github.com>

On Tue, 2 Jan 2024 09:31:16 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.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more cases for 'language encoding' bit set, opened with a different encoding

Thank you for the update. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17207#pullrequestreview-1800190473

From acobbs at openjdk.org  Tue Jan  2 10:16:58 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 2 Jan 2024 10:16:58 GMT
Subject: Integrated: 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: <-bw7-0_OqiWtdwkTrvLw66GsmveJtRrB70ryu4CnmWk=.a703a4f2-e26c-4b81-a834-bfc5cc7ec1aa@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.

This pull request has now been integrated.

Changeset: 5852f3ea
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5852f3eafe4509a064c727371962ff249886e115
Stats:     63 lines in 2 files changed: 62 ins; 0 del; 1 mod

8322027: One XMLStreamException constructor fails to initialize cause

Reviewed-by: joehw, jpai

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

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

From jpai at openjdk.org  Tue Jan  2 10:40:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 10:40:39 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v2]
In-Reply-To: <DK0AgrnseqxVeLsJ6-Mo64_FscIC0d835kAMiMPt5FI=.a6dda530-2ddf-4c96-993b-b6afe53a3cb8@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <DK0AgrnseqxVeLsJ6-Mo64_FscIC0d835kAMiMPt5FI=.a6dda530-2ddf-4c96-993b-b6afe53a3cb8@github.com>
Message-ID: <cXHGmgjIMiJ2r04jDguNvmkhMO9Ccx5YFU-8DG_Zo9E=.05804f68-b707-4f1f-82b2-ab1766ad4799@github.com>

On Tue, 2 Jan 2024 09:14:14 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream.
>> 
>> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
>> 
>> This fix is to move the closing of the wrapped stream inside the finally block.
>> 
>> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
>> 
>> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
>> 
>> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent IOException thrown during finish() from being lost if an IOException is thrown while closing the wrapped stream

src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 257:

> 255:                 } catch (IOException ioe) {
> 256:                     if (finishException != ioe) {
> 257:                         ioe.addSuppressed(finishException);

A null check for `finishException` will be needed here to prevent a `NullPointerException` being thrown from within `addSuppressed`. I think it's better to just copy over (rest of) the finally block from `FilterOutputStream`'s close() method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1439328181

From duke at openjdk.org  Tue Jan  2 11:12:55 2024
From: duke at openjdk.org (ANUPAM DEV)
Date: Tue, 2 Jan 2024 11:12:55 GMT
Subject: Integrated: 8317846: Typo in API documentation of classes
 IdentityHashMap
In-Reply-To: <XIQQWBbbHbLtMEW9_n6hc7usUMlruvDd_HbrkJ8uSnE=.0204425d-93c9-4942-ada4-53c76b722d6a@github.com>
References: <XIQQWBbbHbLtMEW9_n6hc7usUMlruvDd_HbrkJ8uSnE=.0204425d-93c9-4942-ada4-53c76b722d6a@github.com>
Message-ID: <yoQgKMCHcuocXDt5zrA1TXoTFpaPtYsdEU4Jx_xG260=.d515d1f8-fd06-4102-b3cc-89d6910db762@github.com>

On Wed, 11 Oct 2023 04:45:20 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> 
> I have fixed the typo in the comment for the constructor IdentityHashMap(Map<? extends K,? extends V> m)
> 
> before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
> after: Constructs a new identity hash map containing the key-value mappings in the specified map.
> 
> Please review the change.
> 
> Regards,
> Anupam

This pull request has now been integrated.

Changeset: d4fb3088
Author:    ANUPAM DEV <anupam.dev at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4fb30885b007baab243536458a54b6ade610218
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8317846: Typo in API documentation of classes IdentityHashMap

Reviewed-by: mli, jpai

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

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

From pavel.rappo at oracle.com  Tue Jan  2 11:56:08 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 2 Jan 2024 11:56:08 +0000
Subject: Blessed modifier order does not include sealed/non-sealed
Message-ID: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>

I couldn't find any prior discussions on this matter.

I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.

-Pavel


From pavel.rappo at oracle.com  Tue Jan  2 12:08:51 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 2 Jan 2024 12:08:51 +0000
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
Message-ID: <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>

I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1

    8.1.1. Class Modifiers
    ...
    
    ClassModifier:
    (one of)
    Annotation public protected private
    abstract static final sealed non-sealed strictfp
    
    ...

    If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.


Shall I just create a PR?

> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> I couldn't find any prior discussions on this matter.
> 
> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
> 
> -Pavel
> 


From forax at univ-mlv.fr  Tue Jan  2 12:11:37 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 2 Jan 2024 13:11:37 +0100 (CET)
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
Message-ID: <1044527186.92730576.1704197497523.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Pavel Rappo" <pavel.rappo at oracle.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, January 2, 2024 12:56:08 PM
> Subject: Blessed modifier order does not include sealed/non-sealed

> I couldn't find any prior discussions on this matter.
> 
> I noticed that bin/blessed-modifier-order.sh has not been updated for the
> [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed`
> keywords. I also note that we already have cases in OpenJDK where those
> keywords are ordered differently. If we have a consensus on how to extend the
> "blessed order" onto those new keywords, I can create a PR to update the
> script.
> 
> -Pavel

[amber-spec-experts added]

Hello,
For me, sealed, non-sealed and final are (mutually exclusive) modifiers that control of the subtypes of a class.
Given that there is already a blessed order for final, sealed and non-sealed should be at the same place as final.

regards,
R?mi

From alanb at openjdk.org  Tue Jan  2 12:13:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 12:13:49 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v4]
In-Reply-To: <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
Message-ID: <NZ-nhHGOqHc-TY52wsYjJd5faA9_H1TssecjkeYSWhw=.b8b9e07a-3e70-4d7c-8536-263ea482c43c@github.com>

On Tue, 2 Jan 2024 09:31:16 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.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more cases for 'language encoding' bit set, opened with a different encoding

> The change to allow user/application specific arbritary charsets to the `ZipFile` constructor seems to have been done long back in Java 1.7 days as part of JDK-4244499.

There is a lot of history in this area. ZIP dates from the days of MS-DOS where it used IBM 437 for encoding the names of entries. So different to Java where it uses UTF-8 for JAR files and also non-JAR ZIP files. Up to this point (as in JDK 7) there were also issues with the UTF-8 decoding and some forms of supplementary characters. Sherman got things to a good place in JDK 7 and also added the constructors so you can specify the encoding when you obtain it from some out of band means.

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

PR Comment: https://git.openjdk.org/jdk/pull/17207#issuecomment-1873950701

From eirbjo at openjdk.org  Tue Jan  2 12:21:21 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 12:21:21 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v3]
In-Reply-To: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
Message-ID: <8FTG4cDptpPXorOh54YrFPxevoj78O7o0lqWroKssLM=.b2636eef-1248-4fd9-8d9d-820792592c17@github.com>

> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream.
> 
> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
> 
> This fix is to move the closing of the wrapped stream inside the finally block.
> 
> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
> 
> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
> 
> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Add more extensive testing of combined write/close failure modes
 - Don't suppress if finishException is null, mark stream as closed even when closing the wrapped stream failed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17209/files
  - new: https://git.openjdk.org/jdk/pull/17209/files/02707d58..33e7756e

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

  Stats: 149 lines in 2 files changed: 123 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/17209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17209/head:pull/17209

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

From eirbjo at openjdk.org  Tue Jan  2 12:28:49 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 12:28:49 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v2]
In-Reply-To: <cXHGmgjIMiJ2r04jDguNvmkhMO9Ccx5YFU-8DG_Zo9E=.05804f68-b707-4f1f-82b2-ab1766ad4799@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <DK0AgrnseqxVeLsJ6-Mo64_FscIC0d835kAMiMPt5FI=.a6dda530-2ddf-4c96-993b-b6afe53a3cb8@github.com>
 <cXHGmgjIMiJ2r04jDguNvmkhMO9Ccx5YFU-8DG_Zo9E=.05804f68-b707-4f1f-82b2-ab1766ad4799@github.com>
Message-ID: <vnUHKrgNyGBLQPFxNv08kPwFGCl38UIvv5FnB5_ekI8=.c56854a1-5d6f-44aa-87ff-7d2ac171441b@github.com>

On Tue, 2 Jan 2024 10:37:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prevent IOException thrown during finish() from being lost if an IOException is thrown while closing the wrapped stream
>
> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 257:
> 
>> 255:                 } catch (IOException ioe) {
>> 256:                     if (finishException != ioe) {
>> 257:                         ioe.addSuppressed(finishException);
> 
> A null check for `finishException` will be needed here to prevent a `NullPointerException` being thrown from within `addSuppressed`. I think it's better to just copy over (rest of) the finally block from `FilterOutputStream`'s close() method.

Updated the code to align with `FilterOutputStream.close()`:

- Avoid the suppression try/catch for the case where finishException is null
- Move `closed = true;` to the top of the method, this makes sure the wrapped stream is only closed once even in the case where it throws during close. Close should only be attempted once.

I added more test cases including one where both finish and close operations fail, one where finish and close operations throw identical IOException instances and one testing that the wrapped stream is closed only once, even if the close operation throws.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1439403755

From asotona at openjdk.org  Tue Jan  2 12:35:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 12:35:09 GMT
Subject: RFR: 8321540: ClassSignature.parseFrom() throws
 StringIndexOutOfBoundsException for invalid signatures [v2]
In-Reply-To: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
References: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
Message-ID: <VUmr6Axf8Yb34cqvfXybYI3fc8ExC0jtZbf9nb2FuSA=.fc08cd42-6cb4-40a9-ac6a-42021b7c4d80@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

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

  updated copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17058/files
  - new: https://git.openjdk.org/jdk/pull/17058/files/da060bbb..e856dffe

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 asotona at openjdk.org  Tue Jan  2 12:38:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 12:38:37 GMT
Subject: RFR: 8321540: ClassSignature.parseFrom() throws
 StringIndexOutOfBoundsException for invalid signatures [v2]
In-Reply-To: <3vf7u7QrIbZdJfpn_9rvBmbFGMfrnNzztntf2usCLK8=.f347e084-dd9c-41e0-9f38-2f14291951c7@github.com>
References: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
 <3vf7u7QrIbZdJfpn_9rvBmbFGMfrnNzztntf2usCLK8=.f347e084-dd9c-41e0-9f38-2f14291951c7@github.com>
Message-ID: <4eErxNGt78D0bAk2UcY0eXRg1K90cmcTaVqRaGMQVxA=.78c78510-69d2-411b-9139-10d43e4ff542@github.com>

On Tue, 2 Jan 2024 07:17:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I'm guessing you have intentionally not included the original `IndexOutOfBoundsException` as a cause in the `IllegalArgumentException` that gets thrown.

Yes, original exception does not contain any meaningful information.

> Also, it appears that the `SignaturesImpl` is more like an utility class and isn't expected to be used in multi-thread access and thus the reliance on the (non final) instance field `sig` appears OK.

Right, `SignaturesImpl` instance is never exposed for multi-threaded access.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17058#issuecomment-1873974280

From asotona at openjdk.org  Tue Jan  2 12:42:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 12:42:52 GMT
Subject: Integrated: 8321540: ClassSignature.parseFrom() throws
 StringIndexOutOfBoundsException for invalid signatures
In-Reply-To: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
References: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>
Message-ID: <ZAISS3JLWvH06Y_46uHSaZsQ8VJyzhqrezWV04Y6BJU=.ee48462f-1331-44ce-b97e-e6941b7ce79e@github.com>

On Mon, 11 Dec 2023 15:17:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: f9aec02f
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9aec02f3caabb6bc06672c214127f8912449615
Stats:     136 lines in 2 files changed: 103 ins; 5 del; 28 mod

8321540: ClassSignature.parseFrom() throws StringIndexOutOfBoundsException for invalid signatures

Reviewed-by: jpai

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

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

From asotona at openjdk.org  Tue Jan  2 12:43:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 12:43:51 GMT
Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown [v2]
In-Reply-To: <aMJjPAD_oDP6l0bIi-iYnm6ngZIefW_nKtAeqIrssQM=.0db96a0a-91de-41a3-8b64-4f752dfde65b@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
 <71S-mvJz6ZUKrEESzAAWbiwfs5sd0JkSTqavQtkHdfo=.f75af6fd-fb6e-4fe2-9dc1-15ca245a73f9@github.com>
 <aMJjPAD_oDP6l0bIi-iYnm6ngZIefW_nKtAeqIrssQM=.0db96a0a-91de-41a3-8b64-4f752dfde65b@github.com>
Message-ID: <U5or2qYOs1Gdvfe-ftsO9bDo9OuLno8pLd6KnMJSewI=.4acb9ed6-b53d-4c9a-904f-6d61f93982b8@github.com>

On Tue, 2 Jan 2024 07:05:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 283:
> 
>> 281:     public void copyBytesTo(BufWriter buf, int p, int len) {
>> 282:         try {
>> 283:             buf.writeBytes(buffer, p, len);
> 
> `java.lang.classfile.BufWriter` doesn't specify any `@throws` for its `writeXXX` methods. Should it be specified (of course in a separate PR)?

That is a good point, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16762#discussion_r1439414618

From asotona at openjdk.org  Tue Jan  2 12:49:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 12:49:48 GMT
Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown [v2]
In-Reply-To: <U5or2qYOs1Gdvfe-ftsO9bDo9OuLno8pLd6KnMJSewI=.4acb9ed6-b53d-4c9a-904f-6d61f93982b8@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
 <71S-mvJz6ZUKrEESzAAWbiwfs5sd0JkSTqavQtkHdfo=.f75af6fd-fb6e-4fe2-9dc1-15ca245a73f9@github.com>
 <aMJjPAD_oDP6l0bIi-iYnm6ngZIefW_nKtAeqIrssQM=.0db96a0a-91de-41a3-8b64-4f752dfde65b@github.com>
 <U5or2qYOs1Gdvfe-ftsO9bDo9OuLno8pLd6KnMJSewI=.4acb9ed6-b53d-4c9a-904f-6d61f93982b8@github.com>
Message-ID: <4nwNiBRJplxl4S25Ehh7ryXDoj1P_iJ5accDsFtMkt0=.a3bf264e-1ed2-4e99-b905-a2fd17f5559b@github.com>

On Tue, 2 Jan 2024 12:41:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 283:
>> 
>>> 281:     public void copyBytesTo(BufWriter buf, int p, int len) {
>>> 282:         try {
>>> 283:             buf.writeBytes(buffer, p, len);
>> 
>> `java.lang.classfile.BufWriter` doesn't specify any `@throws` for its `writeXXX` methods. Should it be specified (of course in a separate PR)?
>
> That is a good point, thanks!

I've created [JDK-8322847](https://bugs.openjdk.org/browse/JDK-8322847)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16762#discussion_r1439418563

From asotona at openjdk.org  Tue Jan  2 13:02:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 13:02:08 GMT
Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown [v3]
In-Reply-To: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
Message-ID: <5joAhg9r3kf0NKsOKQS5aYGtWsCDoyGp1XKMYyU4y3I=.9e5c0a50-01ad-4e4b-af3e-b317b82c9cbd@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 incrementally with one additional commit since the last revision:

  updated copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16762/files
  - new: https://git.openjdk.org/jdk/pull/16762/files/08bcc548..a16bf6da

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 asotona at openjdk.org  Tue Jan  2 13:02:10 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 13:02:10 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: <ju9OuASG_0WVQ2yRF-lrt3UVsAiQycEXZkwapzRRQL0=.8e68d7a6-1dd7-4b5f-8aed-1bc7fc476f63@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

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/16762#issuecomment-1873994195

From asotona at openjdk.org  Tue Jan  2 13:02:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 13:02:11 GMT
Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown [v2]
In-Reply-To: <aMJjPAD_oDP6l0bIi-iYnm6ngZIefW_nKtAeqIrssQM=.0db96a0a-91de-41a3-8b64-4f752dfde65b@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
 <71S-mvJz6ZUKrEESzAAWbiwfs5sd0JkSTqavQtkHdfo=.f75af6fd-fb6e-4fe2-9dc1-15ca245a73f9@github.com>
 <aMJjPAD_oDP6l0bIi-iYnm6ngZIefW_nKtAeqIrssQM=.0db96a0a-91de-41a3-8b64-4f752dfde65b@github.com>
Message-ID: <gdu9ZoJbkpOWs2d-TWhDXbY62Fsl1p2iOymiY6ucyG4=.b14a2207-9899-4bf3-b307-1e736493cada@github.com>

On Tue, 2 Jan 2024 07:03:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 200:
> 
>> 198:         try {
>> 199:             return buffer[p] & 0xFF;
>> 200:         } catch (IndexOutOfBoundsException e) {
> 
> This and all other catch blocks introduced in this change can be changed to the specific exception type `ArrayIndexOutOfBoundsException`, because all these operations are dealing with only array access. If you prefer catching this more generic `IndexOutOfBoundsException`, that's fine with me.

Yes, I prefer the generic `IndexOutOfBoundsException`, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16762#discussion_r1439426562

From asotona at openjdk.org  Tue Jan  2 13:02:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Jan 2024 13:02:11 GMT
Subject: Integrated: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown
In-Reply-To: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
Message-ID: <wEvwz03tq-UDPWUVT69HQ0QFl1q_oO0wdByY0py1VnA=.a81c93ec-52d8-4b90-8173-273514d3e87b@github.com>

On Tue, 21 Nov 2023 13:59:23 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

This pull request has now been integrated.

Changeset: a5cf4210
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5cf4210cd9c293a9e9bce60dc6d0f08fd838c77
Stats:     71 lines in 2 files changed: 47 ins; 0 del; 24 mod

8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown

Reviewed-by: jpai

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

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

From eirbjo at openjdk.org  Tue Jan  2 13:31:01 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 13:31:01 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v9]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <JTGoqJSqSrp6HysaoHY1cgM-tkhE8u6v4Vt7X0toaXc=.1ab87635-f91d-41f1-88eb-610d7617bc1e@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. A new test case `noentries()` was added, resolving [JDK-8322830](https://bugs.openjdk.org/browse/JDK-8322830)
> 
> `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 Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Add test verifying that ZipFile can open a ZIP file with zero entries

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/85500cd8..669b8da1

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

  Stats: 30 lines in 1 file changed: 28 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 duke at openjdk.org  Tue Jan  2 14:13:52 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 2 Jan 2024 14:13:52 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
Message-ID: <7N-RSj57bmy750gwGeCCjg5cU-vF4i8iDa_MsbD4YjU=.52e762e2-3f40-4f87-8f04-9ac18194e0a0@github.com>

On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

>> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
>> - Cache of JAR files in JarURLConnection class
>> - Cache of JAR/ZIP files in JarFile and ZipFile classes
>> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
>> - Directories and filenames with the same name considered to be the same in ZipFile class
>> - Possible issues when local and central headers conflict in ZipInputStream class
>> 
>> Related JBS report:
>> https://bugs.openjdk.org/browse/JDK-8319122
>
> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed more line breaks
>  - fixed line breaks

Still working on this

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

PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1874073990

From prappo at openjdk.org  Tue Jan  2 14:37:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 2 Jan 2024 14:37:16 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue) [v4]
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: <DCVF-CY868Tn0W_W4gcn1IPQS8MwXYSmtNwf5y6oMDA=.8b1c1264-4fa1-4d41-ba92-c11d7a143934@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 four additional commits since the last revision:

 - Merge branch 'master' into 8311864
 - 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/655442eb..e55dc5c1

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

  Stats: 4826 lines in 316 files changed: 2898 ins; 812 del; 1116 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 prappo at openjdk.org  Tue Jan  2 14:37:27 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 2 Jan 2024 14:37:27 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v10]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@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 17 additional commits since the last revision:

 - Merge branch 'master' into 8310813
 - 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
 - ... and 7 more: https://git.openjdk.org/jdk/compare/cd913e32...252b7378

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/ef8b0c46..252b7378

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

  Stats: 4826 lines in 316 files changed: 2898 ins; 812 del; 1116 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 roger.riggs at oracle.com  Tue Jan  2 14:38:54 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 2 Jan 2024 09:38:54 -0500
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
Message-ID: <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>

Hi Pavel,

yes, a PR would be next.

Happy New Year, Roger

On 1/2/24 7:08 AM, Pavel Rappo wrote:
> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>
>      8.1.1. Class Modifiers
>      ...
>      
>      ClassModifier:
>      (one of)
>      Annotation public protected private
>      abstract static final sealed non-sealed strictfp
>      
>      ...
>
>      If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>
>
> Shall I just create a PR?
>
>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>
>> I couldn't find any prior discussions on this matter.
>>
>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>
>> -Pavel
>>


From alanb at openjdk.org  Tue Jan  2 15:22:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 15:22:05 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
Message-ID: <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@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.

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:

 - Revert changes to TracePinnedThreads.java
 - Sync up from loom repo
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17136/files
  - new: https://git.openjdk.org/jdk/pull/17136/files/b7abfc0a..fe255921

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

  Stats: 3108 lines in 165 files changed: 1976 ins; 659 del; 473 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  Tue Jan  2 15:23:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 15:23:13 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
Message-ID: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>

In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/17219/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17219&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322829
  Stats: 141 lines in 6 files changed: 87 ins; 25 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/17219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17219/head:pull/17219

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

From alanb at openjdk.org  Tue Jan  2 15:23:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 15:23:58 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
Message-ID: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>

-Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.

This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing.

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

Commit messages:
 - Initial commit

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

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

From alanb at openjdk.org  Tue Jan  2 15:24:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 15:24:08 GMT
Subject: RFR: 8322818: Thread::getStackTrace can fail with InternalError if
 virtual thread is timed-parked when pinned
Message-ID: <dRXi6Od3v6dYcDt1vTjQBzJ-CyJL_EU9d0YYhiIDMiE=.4552f5e0-b8bc-4e23-82be-19fbd70ee65f@github.com>

Missed by JDK-8312498, VirtualThread::tryGetStackTrace doesn't handle the TIMED_PINNED state so it's possible for Thread::getStackTrace to throw InternalError when invoked on a virtual thread that quickly transitions from unmounted to  timed-park-while-pinned. This one is needs a stress test to reproduce.

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

Commit messages:
 - No need to restrict stress test to VMContinuations
 - Initial commit

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

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

From stefank at openjdk.org  Tue Jan  2 15:26:03 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:26:03 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging [v3]
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: <vrlxWkNAOY8Ge3TRZzzlzAy0XJoU4g4XwWBI0H0yRas=.b775e29b-1bf7-4e54-a174-094779f3533e@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into executeProcessLogging
 - Remove temporary test
 - Typo
 - Whitespace cleanups
 - 8321718: ProcessTools.executeProcess calls waitFor before logging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17052/files
  - new: https://git.openjdk.org/jdk/pull/17052/files/3275136c..fcba9dbd

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

  Stats: 5347 lines in 349 files changed: 3069 ins; 1071 del; 1207 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 Jan  2 15:26:06 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:26:06 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: <K0aJ228mvRYgFx_qZIpFPLbebS_C6dbsrORbM_hvGg0=.0e02048f-aa85-417b-bcd2-bc49ef5efabb@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

Thanks for reviewing! I'll remove the test, merge, and will do some sanity checks before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/17052#issuecomment-1874162036

From stefank at openjdk.org  Tue Jan  2 15:36:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:07 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v4]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <yEDcAV7XwAPsBX5Z4vPBDDUowP57us2a3WIW5bJ6vyk=.d55a077c-b8c9-4050-ad9d-08337753fbae@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/5d488f42..486dc6d5

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

  Stats: 5249 lines in 348 files changed: 3069 ins; 973 del; 1207 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  Tue Jan  2 15:36:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:10 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: <yDnkf3CvvXwTidrzaz6lrvS6XZVKBLVbJEOqBXwPi6M=.e4ddf28f-f03d-4c37-b831-a7206a202755@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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17049#issuecomment-1874176578

From alanb at openjdk.org  Tue Jan  2 15:49:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 15:49:54 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v19]
In-Reply-To: <xWaXE8akS8aryy6daASVJR6vFh_eSbKPaUfDcH7tsbk=.ebfbf96d-1343-4dec-9fc3-1b7a25e380be@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <xWaXE8akS8aryy6daASVJR6vFh_eSbKPaUfDcH7tsbk=.ebfbf96d-1343-4dec-9fc3-1b7a25e380be@github.com>
Message-ID: <yhErAJS4kc0jxa6U_dqJ5j4njALw32MnACVeZ-NGLOw=.c697f718-1a57-4a34-b49f-e58d6dd666e8@github.com>

On Sat, 30 Dec 2023 16:47: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 incrementally with one additional commit since the last revision:
> 
>   8320971: Fix JavaDoc

Implementation changes looks fine, that's for taking all the feedback to get this one to a good place.

@bplb has been reviewing the test, I'll stay out of that and let Brian finish his review.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1800627205

From jpai at openjdk.org  Tue Jan  2 15:58:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jan 2024 15:58:46 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
In-Reply-To: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
Message-ID: <iAokk3pHOHHeeN_y3HTb8cII3Yow8lAbmKjiiCCn3ig=.38fc9e8e-c7df-4b02-bbab-5824e48bbb5e@github.com>

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing.

Hello Alan, I haven't yet looked in detail the changes, so this merely a comment based on first glance:

> The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking.

I guess that then means that the some pinned threads might not even appear in this generated thread dumps. I can't think of a way where we could at least print something that would at least hint that some pinned threads weren't dumped in the output. This reduces the utility of this system property which is unfortunate, but I do understand the reason.

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

PR Comment: https://git.openjdk.org/jdk/pull/17221#issuecomment-1874208143

From alanb at openjdk.org  Tue Jan  2 16:01:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 16:01:46 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
In-Reply-To: <iAokk3pHOHHeeN_y3HTb8cII3Yow8lAbmKjiiCCn3ig=.38fc9e8e-c7df-4b02-bbab-5824e48bbb5e@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
 <iAokk3pHOHHeeN_y3HTb8cII3Yow8lAbmKjiiCCn3ig=.38fc9e8e-c7df-4b02-bbab-5824e48bbb5e@github.com>
Message-ID: <34CD9p3qT9SqBJYzwtmXW1t4eIgeZ6zEMrHKS0aDntw=.2ec9e0f8-35e8-4fa0-b6d5-bed3182d1956@github.com>

On Tue, 2 Jan 2024 15:56:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I guess that then means that the some pinned threads might not even appear in this generated thread dumps.

Just to be clear. The changes here have no impact on thread dumps, the thread dump generated by jcmd Thread.dump_to_file has all virtual threads, including pinned threads.

As regards jdk.tracePinnedThreads. We want this system property to go away, it's just unfortunate that it seems to be widely used.

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

PR Comment: https://git.openjdk.org/jdk/pull/17221#issuecomment-1874211812

From acobbs at openjdk.org  Tue Jan  2 16:30:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 2 Jan 2024 16:30:56 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to
 initialize cause
In-Reply-To: <BXJN2wb4GUwuT7O1aWHochbYoVdbEt2tIxP-C1PXCvo=.9a1fa055-6999-4370-ad55-9b12a5fde132@github.com>
References: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
 <BXJN2wb4GUwuT7O1aWHochbYoVdbEt2tIxP-C1PXCvo=.9a1fa055-6999-4370-ad55-9b12a5fde132@github.com>
Message-ID: <OC2aOeRk77NItXsujOroK1m3d0Bg1KVlZ6BbCZ3SQdw=.a0e6549e-54d8-4fe9-867f-4fc4ed6f08d0@github.com>

On Tue, 2 Jan 2024 06:47:52 GMT, Jaikiran Pai <jpai 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.
>
> Hello Archie, the changes look fine to me. I see that Joe has approved this change and the CSR too has been approved. I've triggered a CI run to verify there's no unexpected issues. Once that completes, I'll go ahead and sponsor this.

@jaikiran - thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17090#issuecomment-1874251561

From pavel.rappo at oracle.com  Tue Jan  2 16:31:06 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 2 Jan 2024 16:31:06 +0000
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
Message-ID: <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>

Hi Roger,

Happy New Year to you too!

Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int)) hasn't changed since 2009 and states that:

    ...The modifier names are returned in an order consistent with the suggested modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of The Java Language Specification. The full modifier ordering used by this method is:

    public protected private abstract static final transient volatile synchronized native strictfp interface

It does not seem like `sealed` and `non-sealed` are even modelled by java.lang.reflect.Modifier, although `sealed` is modelled by `java.lang.Class#isSealed`. It cannot be overlook, can it?

> On 2 Jan 2024, at 14:38, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi Pavel,
> 
> yes, a PR would be next.
> 
> Happy New Year, Roger
> 
> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>> 
>>     8.1.1. Class Modifiers
>>     ...
>>          ClassModifier:
>>     (one of)
>>     Annotation public protected private
>>     abstract static final sealed non-sealed strictfp
>>          ...
>> 
>>     If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>> 
>> 
>> Shall I just create a PR?
>> 
>>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>> 
>>> I couldn't find any prior discussions on this matter.
>>> 
>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>> 
>>> -Pavel
>>> 
> 


From lancea at openjdk.org  Tue Jan  2 16:47:40 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 Jan 2024 16:47:40 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v4]
In-Reply-To: <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
Message-ID: <s7A4I3171suacpClSL9YW_fhMaVdEs68nELp5owwQuk=.880913bd-981c-4727-a57f-4e2146f5424c@github.com>

On Tue, 2 Jan 2024 09:31:16 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.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more cases for 'language encoding' bit set, opened with a different encoding

Looks good over all.  One minor comment to consider before pushing

test/jdk/java/util/zip/ZipCoding.java line 130:

> 128:             assertEquals(name, e.getName());
> 129:             assertNull(e.getComment()); // No comment in the LOC header
> 130:             assertArrayEquals(ENTRY_DATA, zis.readAllBytes(), "ZipIS content doesn't match!");

Minor Nit, but perhaps changes the "ZipIS content..." message to make it clearer as it is not what is clear what ZipIS is...

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17207#pullrequestreview-1800709897
PR Review Comment: https://git.openjdk.org/jdk/pull/17207#discussion_r1439626614

From roger.riggs at oracle.com  Tue Jan  2 16:56:07 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 2 Jan 2024 11:56:07 -0500
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
 <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
Message-ID: <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>

Hi Pavel,

It better to look to javax.lang.model.element.Modifier 
<https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/lang/model/element/Modifier.html> 
for the language view of the class.

java.lang.reflect.Modifier covers the modifier flags as represented in 
the class file and defined in the JVMS.

* The values for the constants * representing the modifiers are taken 
from the tables in sections * {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and 
{@jvms 4.7} of * <cite>The Java Virtual Machine Specification</cite>.

Sealing is represented in the class file as a non-empty list of 
permitted classes. Hence the method of java.lang.Class.

Since java.lang.Modifier.toString is based on the flag bits from the 
class file, "sealed" would not appear in any string it generates.


It might be possible to inject a comment in the toString method similar 
to the comment about interface not being a true modifier and including a 
reference to the javax.lang.model.element.Modifier enum.

Roger


On 1/2/24 11:31 AM, Pavel Rappo wrote:
> Hi Roger,
>
> Happy New Year to you too!
>
> Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int))  hasn't changed since 2009 and states that:
>
>      ...The modifier names are returned in an order consistent with the suggested modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of The Java Language Specification. The full modifier ordering used by this method is:
>
>      public protected private abstract static final transient volatile synchronized native strictfp interface
>
> It does not seem like `sealed` and `non-sealed` are even modelled by java.lang.reflect.Modifier, although `sealed` is modelled by `java.lang.Class#isSealed`. It cannot be overlook, can it?
>
>> On 2 Jan 2024, at 14:38, Roger Riggs<roger.riggs at oracle.com>  wrote:
>>
>> Hi Pavel,
>>
>> yes, a PR would be next.
>>
>> Happy New Year, Roger
>>
>> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>>> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS:https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>>>
>>>      8.1.1. Class Modifiers
>>>      ...
>>>           ClassModifier:
>>>      (one of)
>>>      Annotation public protected private
>>>      abstract static final sealed non-sealed strictfp
>>>           ...
>>>
>>>      If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>>>
>>>
>>> Shall I just create a PR?
>>>
>>>> On 2 Jan 2024, at 11:56, Pavel Rappo<pavel.rappo at oracle.com>  wrote:
>>>>
>>>> I couldn't find any prior discussions on this matter.
>>>>
>>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>>>
>>>> -Pavel
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240102/7ac4ff55/attachment.htm>

From pavel.rappo at oracle.com  Tue Jan  2 17:18:33 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 2 Jan 2024 17:18:33 +0000
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
 <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
 <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>
Message-ID: <BC72F246-A12F-4387-889E-A7F314A6A56E@oracle.com>

Right, the language model (javax.lang.model) is a better target to refer to when considering _source_ files. However, java.lang.reflect.Modifier corresponds to a set returned by javax.lang.model.element.Element#getModifiers, not to a single instance of javax.lang.model.element.Modifier; the order of that set is unspecified.

So perhaps the right thing would be to directly refer to JLS from the script. What do you think?

> On 2 Jan 2024, at 16:56, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi Pavel,
> 
> It better to look to javax.lang.model.element.Modifier for the language view of the class.
> 
> java.lang.reflect.Modifier covers the modifier flags as represented in the class file and defined in the JVMS.
> * The values for the constants
> * representing the modifiers are taken from the tables in sections
> * {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and {@jvms 4.7} of
> * <cite>The Java Virtual Machine Specification</cite>.
> Sealing is represented in the class file as a non-empty list of permitted classes. Hence the method of java.lang.Class.
> 
> Since java.lang.Modifier.toString is based on the flag bits from the class file, "sealed" would not appear in any string it generates.
> 
> 
> It might be possible to inject a comment in the toString method similar to the comment about interface not being a true modifier and including a reference to the javax.lang.model.element.Modifier enum.
> 
> Roger
> 
> 
> On 1/2/24 11:31 AM, Pavel Rappo wrote:
>> Hi Roger,
>> 
>> Happy New Year to you too!
>> 
>> Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int)) hasn't changed since 2009 and states that:
>> 
>> ...The modifier names are returned in an order consistent with the suggested modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of The Java Language Specification. The full modifier ordering used by this method is:
>> 
>> public protected private abstract static final transient volatile synchronized native strictfp interface
>> 
>> It does not seem like `sealed` and `non-sealed` are even modelled by java.lang.reflect.Modifier, although `sealed` is modelled by `java.lang.Class#isSealed`. It cannot be overlook, can it?
>> 
>> 
>>> On 2 Jan 2024, at 14:38, Roger Riggs <roger.riggs at oracle.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>> yes, a PR would be next.
>>> 
>>> Happy New Year, Roger
>>> 
>>> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>>> 
>>>> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>>>> 
>>>> 8.1.1. Class Modifiers
>>>> ...
>>>> ClassModifier:
>>>> (one of)
>>>> Annotation public protected private
>>>> abstract static final sealed non-sealed strictfp
>>>> ...
>>>> 
>>>> If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>>>> 
>>>> 
>>>> Shall I just create a PR?
>>>> 
>>>> 
>>>>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>> 
>>>>> I couldn't find any prior discussions on this matter.
>>>>> 
>>>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>>>> 
>>>>> -Pavel
>>>>> 
>>>>> 
>>> 
>> 
> 


From eirbjo at openjdk.org  Tue Jan  2 17:21:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 17:21:13 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v5]
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: <lFkv0dR1hosf652lqB3P5JRRLiTOLXfUQdn0CY03HaE=.cdfcc854-d15d-4177-9d59-259151ff9d99@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:

  Update some assertion failure messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17207/files
  - new: https://git.openjdk.org/jdk/pull/17207/files/4f53308c..8ba24628

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

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 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  Tue Jan  2 17:21:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 17:21:13 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v4]
In-Reply-To: <s7A4I3171suacpClSL9YW_fhMaVdEs68nELp5owwQuk=.880913bd-981c-4727-a57f-4e2146f5424c@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <2tbBP4aL1H0RJ7CbonLkTCp5Yc-aQ-jNn9ogjptHaXg=.08039f4d-d6c6-45f8-b815-3687009ea621@github.com>
 <s7A4I3171suacpClSL9YW_fhMaVdEs68nELp5owwQuk=.880913bd-981c-4727-a57f-4e2146f5424c@github.com>
Message-ID: <FpXTiSX3DIynr5cIn5Z0J9u3EMRtiyuAXIpExdKtsEI=.dddeea49-426d-41ec-8cd2-eb57100663da@github.com>

On Tue, 2 Jan 2024 16:43:29 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more cases for 'language encoding' bit set, opened with a different encoding
>
> test/jdk/java/util/zip/ZipCoding.java line 130:
> 
>> 128:             assertEquals(name, e.getName());
>> 129:             assertNull(e.getComment()); // No comment in the LOC header
>> 130:             assertArrayEquals(ENTRY_DATA, zis.readAllBytes(), "ZipIS content doesn't match!");
> 
> Minor Nit, but perhaps changes the "ZipIS content..." message to make it clearer as it is not what is clear what ZipIS is...

These messages were mostly carried over. I updated this one to "ZIP entry data does not match". Also updated a few other assertion messages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17207#discussion_r1439654471

From roger.riggs at oracle.com  Tue Jan  2 17:23:52 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 2 Jan 2024 12:23:52 -0500
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <BC72F246-A12F-4387-889E-A7F314A6A56E@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
 <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
 <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>
 <BC72F246-A12F-4387-889E-A7F314A6A56E@oracle.com>
Message-ID: <1d50d099-8033-4c50-920e-7e356d9fb243@oracle.com>

Hi Pavel,

I agree, the script should refer to the JLS.
Some people look to the javadoc but its not authoritative on the language.

Roger

On 1/2/24 12:18 PM, Pavel Rappo wrote:
> Right, the language model (javax.lang.model) is a better target to refer to when considering _source_ files. However, java.lang.reflect.Modifier corresponds to a set returned by javax.lang.model.element.Element#getModifiers, not to a single instance of javax.lang.model.element.Modifier; the order of that set is unspecified.
>
> So perhaps the right thing would be to directly refer to JLS from the script. What do you think?
>
>> On 2 Jan 2024, at 16:56, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> It better to look to javax.lang.model.element.Modifier for the language view of the class.
>>
>> java.lang.reflect.Modifier covers the modifier flags as represented in the class file and defined in the JVMS.
>> * The values for the constants
>> * representing the modifiers are taken from the tables in sections
>> * {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and {@jvms 4.7} of
>> * <cite>The Java Virtual Machine Specification</cite>.
>> Sealing is represented in the class file as a non-empty list of permitted classes. Hence the method of java.lang.Class.
>>
>> Since java.lang.Modifier.toString is based on the flag bits from the class file, "sealed" would not appear in any string it generates.
>>
>>
>> It might be possible to inject a comment in the toString method similar to the comment about interface not being a true modifier and including a reference to the javax.lang.model.element.Modifier enum.
>>
>> Roger
>>
>>
>> On 1/2/24 11:31 AM, Pavel Rappo wrote:
>>> Hi Roger,
>>>
>>> Happy New Year to you too!
>>>
>>> Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int)) hasn't changed since 2009 and states that:
>>>
>>> ...The modifier names are returned in an order consistent with the suggested modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of The Java Language Specification. The full modifier ordering used by this method is:
>>>
>>> public protected private abstract static final transient volatile synchronized native strictfp interface
>>>
>>> It does not seem like `sealed` and `non-sealed` are even modelled by java.lang.reflect.Modifier, although `sealed` is modelled by `java.lang.Class#isSealed`. It cannot be overlook, can it?
>>>
>>>
>>>> On 2 Jan 2024, at 14:38, Roger Riggs <roger.riggs at oracle.com> wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>> yes, a PR would be next.
>>>>
>>>> Happy New Year, Roger
>>>>
>>>> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>>>>
>>>>> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>>>>>
>>>>> 8.1.1. Class Modifiers
>>>>> ...
>>>>> ClassModifier:
>>>>> (one of)
>>>>> Annotation public protected private
>>>>> abstract static final sealed non-sealed strictfp
>>>>> ...
>>>>>
>>>>> If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>>>>>
>>>>>
>>>>> Shall I just create a PR?
>>>>>
>>>>>
>>>>>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>>>
>>>>>> I couldn't find any prior discussions on this matter.
>>>>>>
>>>>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>>>>>
>>>>>> -Pavel
>>>>>>
>>>>>>


From eirbjo at openjdk.org  Tue Jan  2 17:50:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 17:50:51 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v6]
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: <ePv8Wr5zVpuuh-qZqgZ-I3q21chmH95rnB03O-S7aa4=.9b2445c7-dc40-4cb9-8952-b7f8becebbf0@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:

  Fine tuning assertion messages for consistency between tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17207/files
  - new: https://git.openjdk.org/jdk/pull/17207/files/8ba24628..dfdfb5bf

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

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 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 bpb at openjdk.org  Tue Jan  2 18:08:49 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Jan 2024 18:08:49 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: <xvCWHfz-3lS_kso3gpDvVUXpxPawtsguysviqxYkkAg=.74af40b1-6f1b-43e6-b86e-961a4a8136d1@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/aed73e30...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 has been reviewing the test, I'll stay out of that and let Brian finish his review.

I think that the test looks all right, but the copyright might need to be changed to `2023, 2024` instead of just `2023` as it is a new file. The source file does not need `2024` if no changes have been made in the last two days.

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

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

From forax at univ-mlv.fr  Tue Jan  2 18:29:43 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 2 Jan 2024 19:29:43 +0100 (CET)
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
 <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
Message-ID: <1801825645.92846850.1704220183637.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Pavel Rappo" <pavel.rappo at oracle.com>
> To: "Roger Riggs" <roger.riggs at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, January 2, 2024 5:31:06 PM
> Subject: Re: Blessed modifier order does not include sealed/non-sealed

> Hi Roger,
> 
> Happy New Year to you too!
> 
> Although it's a _somewhat_ separate issue, I found that the shell script refers
> to java.lang.reflect.Modifier#toString which does NOT mention either `sealed`
> or `non-sealed`. More precisely, the script refers to the JDK 8 version of that
> method, but [the
> method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int))
> hasn't changed since 2009 and states that:
> 
>    ...The modifier names are returned in an order consistent with the suggested
>    modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of
>    The Java Language Specification. The full modifier ordering used by this method
>    is:
> 
>    public protected private abstract static final transient volatile synchronized
>    native strictfp interface
> 
> It does not seem like `sealed` and `non-sealed` are even modelled by
> java.lang.reflect.Modifier, although `sealed` is modelled by
> `java.lang.Class#isSealed`. It cannot be overlook, can it?

There was always an ambiguity with the package java.lang.reflect, because it reflects the classfile (the .class) and not the source file (the .java).
So j.l.r.Modifier and j.l.r.AccessFlag reflects the modifiers of the classfile, see [1].

The keyword sealed and non-sealed are modifiers in the source file but not in the classfile. Sealed is represented as the attribute PermittedSubclasses and non-sealed is just no modifier (you have to op-out when a hierarchy is sealed in the source file while for the classfile it's opt-in). That's why both sealed and non-sealed are not defined in Modifier.

regards,
R?mi

[1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/AccessFlag.html

> 
>> On 2 Jan 2024, at 14:38, Roger Riggs <roger.riggs at oracle.com> wrote:
>> 
>> Hi Pavel,
>> 
>> yes, a PR would be next.
>> 
>> Happy New Year, Roger
>> 
>> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>>> I assume the order for `sealed` and `non-sealed` has effectively been decided by
>>> JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>>> 
>>>     8.1.1. Class Modifiers
>>>     ...
>>>          ClassModifier:
>>>     (one of)
>>>     Annotation public protected private
>>>     abstract static final sealed non-sealed strictfp
>>>          ...
>>> 
>>>     If two or more (distinct) class modifiers appear in a class declaration, then it
>>>     is customary, though not required, that they appear in the order consistent
>>>     with that shown above in the production for ClassModifier.
>>> 
>>> 
>>> Shall I just create a PR?
>>> 
>>>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> I couldn't find any prior discussions on this matter.
>>>> 
>>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the
>>>> [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed`
>>>> keywords. I also note that we already have cases in OpenJDK where those
>>>> keywords are ordered differently. If we have a consensus on how to extend the
>>>> "blessed order" onto those new keywords, I can create a PR to update the
>>>> script.
>>>> 
>>>> -Pavel
>>>> 

From stsypanov at openjdk.org  Tue Jan  2 20:03:01 2024
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 2 Jan 2024 20:03:01 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v20]
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: <QnQstBcswYw6_9CYsi5wCWsTzrLqmZ-Ve4D-3832TRQ=.3a4499f0-8a54-47f9-89f7-fd69a7439056@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:

  Update TransferToTrusted.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/e769dfb2..8d15e748

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=18-19

  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 bpb at openjdk.org  Tue Jan  2 20:03:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Jan 2024 20:03:01 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v20]
In-Reply-To: <QnQstBcswYw6_9CYsi5wCWsTzrLqmZ-Ve4D-3832TRQ=.3a4499f0-8a54-47f9-89f7-fd69a7439056@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <QnQstBcswYw6_9CYsi5wCWsTzrLqmZ-Ve4D-3832TRQ=.3a4499f0-8a54-47f9-89f7-fd69a7439056@github.com>
Message-ID: <YubdqL5JtMRRpBWa-PZw2_sVAXbnL8vF0ZymfyGN394=.3c962a08-4a27-4a74-9c1f-34c5ccba572d@github.com>

On Tue, 2 Jan 2024 20:00: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:
> 
>   Update TransferToTrusted.java

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1800941486

From stsypanov at openjdk.org  Tue Jan  2 20:09:01 2024
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 2 Jan 2024 20:09:01 GMT
Subject: Integrated: 8320971: Use BufferedInputStream.buf directly when param
 of implTransferTo() is trusted
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: <68aAdE-jpUpTXIZttqVil95sUYJLSe89GY_RspIZF8I=.beeb2387-2add-431a-a960-4433afdfae0d@github.com>

On Wed, 29 Nov 2023 11:57:37 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

This pull request has now been integrated.

Changeset: 38042ad4
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38042ad4e9b57d79cd795fd22d31be63924e34c5
Stats:     114 lines in 2 files changed: 111 ins; 0 del; 3 mod

8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted

Reviewed-by: alanb, bpb

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

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

From lancea at openjdk.org  Tue Jan  2 20:26:41 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 Jan 2024 20:26:41 GMT
Subject: RFR: 8322802: Add testing for ZipFile.getEntry respecting the
 'Language encoding' flag [v6]
In-Reply-To: <ePv8Wr5zVpuuh-qZqgZ-I3q21chmH95rnB03O-S7aa4=.9b2445c7-dc40-4cb9-8952-b7f8becebbf0@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <ePv8Wr5zVpuuh-qZqgZ-I3q21chmH95rnB03O-S7aa4=.9b2445c7-dc40-4cb9-8952-b7f8becebbf0@github.com>
Message-ID: <qSLJEK5lbmbfdKtmtHEatrwrtVqN0qm4uMfXZpIbzjI=.d536a04c-c8f3-4420-9f9d-40f7b7a4640d@github.com>

On Tue, 2 Jan 2024 17:50:51 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.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fine tuning assertion messages for consistency between tests

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17207#pullrequestreview-1800965421

From bpb at openjdk.org  Tue Jan  2 20:33:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Jan 2024 20:33:04 GMT
Subject: RFR: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has
 bad copyright header
Message-ID: <0SGITCMX8BVTksBkO8qDWHkR5CkhXVaIQZsc2oDjvIE=.5fc26c57-89fd-4cc6-a54b-b3e0ed939306@github.com>

Add missing comma after 2024.

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

Commit messages:
 - 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

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

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

From eirbjo at openjdk.org  Tue Jan  2 20:34:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 20:34:53 GMT
Subject: Integrated: 8322802: Add testing for ZipFile.getEntry respecting 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: <own41J0uTCFrihpSNNfNXAUEICWsw5MV3oJqSGEcyyQ=.760e2bb0-2bb7-4ada-a9e4-af18978348b2@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.

This pull request has now been integrated.

Changeset: 2cf5f013
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cf5f0139740c6d822225848fc1691e144a6ed1a
Stats:     168 lines in 1 file changed: 96 ins; 22 del; 50 mod

8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag

Reviewed-by: lancea, jpai

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

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

From dcubed at openjdk.org  Tue Jan  2 20:37:51 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 2 Jan 2024 20:37:51 GMT
Subject: RFR: 8322868: java/io/BufferedInputStream/TransferToTrusted.java
 has bad copyright header
In-Reply-To: <0SGITCMX8BVTksBkO8qDWHkR5CkhXVaIQZsc2oDjvIE=.5fc26c57-89fd-4cc6-a54b-b3e0ed939306@github.com>
References: <0SGITCMX8BVTksBkO8qDWHkR5CkhXVaIQZsc2oDjvIE=.5fc26c57-89fd-4cc6-a54b-b3e0ed939306@github.com>
Message-ID: <7HKDpPefRIwiHsyBE4OzMF1dMed4tvbUS0CV7mVf6XE=.91e67560-f855-4427-8aa8-81d5d0a03af5@github.com>

On Tue, 2 Jan 2024 20:27:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add missing comma after 2024.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17228#pullrequestreview-1800974980

From bpb at openjdk.org  Tue Jan  2 20:37:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Jan 2024 20:37:52 GMT
Subject: Integrated: 8322868:
 java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header
In-Reply-To: <0SGITCMX8BVTksBkO8qDWHkR5CkhXVaIQZsc2oDjvIE=.5fc26c57-89fd-4cc6-a54b-b3e0ed939306@github.com>
References: <0SGITCMX8BVTksBkO8qDWHkR5CkhXVaIQZsc2oDjvIE=.5fc26c57-89fd-4cc6-a54b-b3e0ed939306@github.com>
Message-ID: <4Na6BsmNYzLbWtW9saA8-WDyeyfiA9EEi7DByHsEdAI=.c5ec1cd5-733d-4b70-abbf-8c63f84fc9ec@github.com>

On Tue, 2 Jan 2024 20:27:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add missing comma after 2024.

This pull request has now been integrated.

Changeset: c2477a5c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2477a5cad6539e6e38cc0732383aaa2a8df801f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

Reviewed-by: dcubed

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

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

From eirbjo at openjdk.org  Tue Jan  2 22:09:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jan 2024 22:09:46 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v3]
In-Reply-To: <8FTG4cDptpPXorOh54YrFPxevoj78O7o0lqWroKssLM=.b2636eef-1248-4fd9-8d9d-820792592c17@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <8FTG4cDptpPXorOh54YrFPxevoj78O7o0lqWroKssLM=.b2636eef-1248-4fd9-8d9d-820792592c17@github.com>
Message-ID: <ldznYfAiW9dA7mx8lUuKsAzLp_KDo1y2VZ1_GBZFA7A=.a8d0497d-08b5-4268-a74c-c634e80380bf@github.com>

On Tue, 2 Jan 2024 12:21:21 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once.
>> 
>> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
>> 
>> This fix is to move the closing of the wrapped stream inside the finally block.
>> 
>> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?)
>> 
>> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
>> 
>> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
>> 
>> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more extensive testing of combined write/close failure modes
>  - Don't suppress if finishException is null, mark stream as closed even when closing the wrapped stream failed

A CSR for this change has been proposed and is ready for review: [JDK-8322871](https://bugs.openjdk.org/browse/JDK-8322871)

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

PR Comment: https://git.openjdk.org/jdk/pull/17209#issuecomment-1874623292

From pavel.rappo at oracle.com  Tue Jan  2 23:06:30 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 2 Jan 2024 23:06:30 +0000
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <1d50d099-8033-4c50-920e-7e356d9fb243@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
 <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
 <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>
 <BC72F246-A12F-4387-889E-A7F314A6A56E@oracle.com>
 <1d50d099-8033-4c50-920e-7e356d9fb243@oracle.com>
Message-ID: <45535740-3FF5-42D4-91AD-3C02CF96BE9D@oracle.com>

While we are here, I also note that the script does not explicitly take into account the `default` modifier on an interface method. However, after reading https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.4 it seems that whenever `default` appears, it should be alone one way or another; thus, ordering is not an issue.

Indeed, here are the modifier possibilities for an interface method declaration:

    public private abstract default static strictfp

And here are the relevant constraints:

  - explicit public is discouraged
  - abstract, default, and static are mutually exclusive
  - strictfp is obsolete
  - private and default are mutually exclusive

So if `default` appears, except for uncompilable, discouraged, or obsolete cases, it should be alone. Thoughts?

> On 2 Jan 2024, at 17:23, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi Pavel,
> 
> I agree, the script should refer to the JLS.
> Some people look to the javadoc but its not authoritative on the language.
> 
> Roger
> 
> On 1/2/24 12:18 PM, Pavel Rappo wrote:
>> Right, the language model (javax.lang.model) is a better target to refer to when considering _source_ files. However, java.lang.reflect.Modifier corresponds to a set returned by javax.lang.model.element.Element#getModifiers, not to a single instance of javax.lang.model.element.Modifier; the order of that set is unspecified.
>> 
>> So perhaps the right thing would be to directly refer to JLS from the script. What do you think?
>> 
>>> On 2 Jan 2024, at 16:56, Roger Riggs <roger.riggs at oracle.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>> It better to look to javax.lang.model.element.Modifier for the language view of the class.
>>> 
>>> java.lang.reflect.Modifier covers the modifier flags as represented in the class file and defined in the JVMS.
>>> * The values for the constants
>>> * representing the modifiers are taken from the tables in sections
>>> * {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and {@jvms 4.7} of
>>> * <cite>The Java Virtual Machine Specification</cite>.
>>> Sealing is represented in the class file as a non-empty list of permitted classes. Hence the method of java.lang.Class.
>>> 
>>> Since java.lang.Modifier.toString is based on the flag bits from the class file, "sealed" would not appear in any string it generates.
>>> 
>>> 
>>> It might be possible to inject a comment in the toString method similar to the comment about interface not being a true modifier and including a reference to the javax.lang.model.element.Modifier enum.
>>> 
>>> Roger
>>> 
>>> 
>>> On 1/2/24 11:31 AM, Pavel Rappo wrote:
>>>> Hi Roger,
>>>> 
>>>> Happy New Year to you too!
>>>> 
>>>> Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int)) hasn't changed since 2009 and states that:
>>>> 
>>>> ...The modifier names are returned in an order consistent with the suggested modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of The Java Language Specification. The full modifier ordering used by this method is:
>>>> 
>>>> public protected private abstract static final transient volatile synchronized native strictfp interface
>>>> 
>>>> It does not seem like `sealed` and `non-sealed` are even modelled by java.lang.reflect.Modifier, although `sealed` is modelled by `java.lang.Class#isSealed`. It cannot be overlook, can it?
>>>> 
>>>> 
>>>>> On 2 Jan 2024, at 14:38, Roger Riggs <roger.riggs at oracle.com> wrote:
>>>>> 
>>>>> Hi Pavel,
>>>>> 
>>>>> yes, a PR would be next.
>>>>> 
>>>>> Happy New Year, Roger
>>>>> 
>>>>> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>>>>> 
>>>>>> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>>>>>> 
>>>>>> 8.1.1. Class Modifiers
>>>>>> ...
>>>>>> ClassModifier:
>>>>>> (one of)
>>>>>> Annotation public protected private
>>>>>> abstract static final sealed non-sealed strictfp
>>>>>> ...
>>>>>> 
>>>>>> If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>>>>>> 
>>>>>> 
>>>>>> Shall I just create a PR?
>>>>>> 
>>>>>> 
>>>>>>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>>>> 
>>>>>>> I couldn't find any prior discussions on this matter.
>>>>>>> 
>>>>>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>>>>>> 
>>>>>>> -Pavel
>>>>>>> 
>>>>>>> 
> 


From ccheung at openjdk.org  Wed Jan  3 00:49:01 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 3 Jan 2024 00:49:01 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v3]
In-Reply-To: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
Message-ID: <KL6Z0bEYXtPb0g7uD6wCp5C_tFQxskZXb2pzeSpY6kk=.94955a75-143d-40a3-831a-18b4d8702700@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:

  tests update per discussion with Ioi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17178/files
  - new: https://git.openjdk.org/jdk/pull/17178/files/d06b98ff..a2e9f668

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

  Stats: 4 lines in 2 files changed: 1 ins; 1 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 joe.darcy at oracle.com  Wed Jan  3 01:49:39 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 2 Jan 2024 17:49:39 -0800
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
 <84a0413a-252c-4c0e-8e8d-dabc840ae5a5@oracle.com>
 <355BA0BB-4543-4598-BFE1-09984CF8D2EE@oracle.com>
 <24710123-fde3-4412-b2a7-e5981a713ba6@oracle.com>
Message-ID: <be5d4b95-1105-4f9f-bba0-0073827ae406@oracle.com>

Hello,

Some time back, the java.lang.reflect package level docs had a brief 
discussion added concerning what exactly core reflection is modeling. 
[1]. tl;dr -- mostly a class file level view. As such, a contingent 
property of the design of JEP 409 is that sealed/non-sealed happens to 
_not_ to expressed JVM-level access flags/modifiers. However, it would 
be reasonable IMO for Class.toGenericString(), but not Class.toString(), 
to be updated to expose some sealing-related information. I've filed 
JDK-8322878: "Including sealing information Class.toGenericString()."

-Joe

[1] Added under ??? JDK-8262807: "Note assumptions of core reflection 
modeling and parameter handling" in JDK 17:

> Java programming language and JVM modeling in core reflection
>
> The components of core reflection, which include types in this package 
> as well as Class, Package, and Module, fundamentally present a JVM 
> model of the entities in question rather than a Java programming 
> language model. A Java compiler, such as javac, translates Java source 
> code into executable output that can be run on a JVM, primarily class 
> files. Compilers for source languages other than Java can and do 
> target the JVM as well.
>
> The translation process, including from Java language sources, to 
> executable output for the JVM is not a one-to-one mapping. Structures 
> present in the source language may have no representation in the 
> output and structures not present in the source language may be 
> present in the output. The latter are called synthetic structures. 
> Synthetic structures can include methods, fields, parameters, classes 
> and interfaces. One particular kind of synthetic method is a bridge 
> method. It is possible a synthetic structure may not be marked as 
> such. In particular, not all class file versions support marking a 
> parameter as synthetic. A source language compiler generally has 
> multiple ways to translate a source program into a class file 
> representation. The translation may also depend on the version of the 
> class file format being targeted as different class file versions have 
> different capabilities and features. In some cases the modifiers 
> present in the class file representation may differ from the modifiers 
> on the originating element in the source language, including final on 
> a parameter and protected, private, and static on classes and interfaces.
>
> Besides differences in structural representation between the source 
> language and the JVM representation, core reflection also exposes 
> runtime specific information. For example, the class loaders and 
> protection domains of a Class are runtime concepts without a direct 
> analogue in source code.

https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/reflect/package-summary.html

On 1/2/2024 8:56 AM, Roger Riggs wrote:
> Hi Pavel,
>
> It better to look to javax.lang.model.element.Modifier 
> <https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/lang/model/element/Modifier.html> 
> for the language view of the class.
>
> java.lang.reflect.Modifier covers the modifier flags as represented in 
> the class file and defined in the JVMS.
> * The values for the constants * representing the modifiers are taken 
> from the tables in sections * {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, 
> and {@jvms 4.7} of * <cite>The Java Virtual Machine Specification</cite>.
> Sealing is represented in the class file as a non-empty list of 
> permitted classes. Hence the method of java.lang.Class.
>
> Since java.lang.Modifier.toString is based on the flag bits from the 
> class file, "sealed" would not appear in any string it generates.
>
>
> It might be possible to inject a comment in the toString method 
> similar to the comment about interface not being a true modifier and 
> including a reference to the javax.lang.model.element.Modifier enum.
>
> Roger
>
>
> On 1/2/24 11:31 AM, Pavel Rappo wrote:
>> Hi Roger,
>>
>> Happy New Year to you too!
>>
>> Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int))  hasn't changed since 2009 and states that:
>>
>>      ...The modifier names are returned in an order consistent with the suggested modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of The Java Language Specification. The full modifier ordering used by this method is:
>>
>>      public protected private abstract static final transient volatile synchronized native strictfp interface
>>
>> It does not seem like `sealed` and `non-sealed` are even modelled by java.lang.reflect.Modifier, although `sealed` is modelled by `java.lang.Class#isSealed`. It cannot be overlook, can it?
>>
>>> On 2 Jan 2024, at 14:38, Roger Riggs<roger.riggs at oracle.com>  wrote:
>>>
>>> Hi Pavel,
>>>
>>> yes, a PR would be next.
>>>
>>> Happy New Year, Roger
>>>
>>> On 1/2/24 7:08 AM, Pavel Rappo wrote:
>>>> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS:https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>>>>
>>>>      8.1.1. Class Modifiers
>>>>      ...
>>>>           ClassModifier:
>>>>      (one of)
>>>>      Annotation public protected private
>>>>      abstract static final sealed non-sealed strictfp
>>>>           ...
>>>>
>>>>      If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>>>>
>>>>
>>>> Shall I just create a PR?
>>>>
>>>>> On 2 Jan 2024, at 11:56, Pavel Rappo<pavel.rappo at oracle.com>  wrote:
>>>>>
>>>>> I couldn't find any prior discussions on this matter.
>>>>>
>>>>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>>>>
>>>>> -Pavel
>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240102/40557aa8/attachment-0001.htm>

From joe.darcy at oracle.com  Wed Jan  3 02:14:11 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 2 Jan 2024 18:14:11 -0800
Subject: Blessed modifier order does not include sealed/non-sealed
In-Reply-To: <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
References: <DDA36D08-AA46-4250-9D6E-DE3DD03330BE@oracle.com>
 <34B70FF4-3694-4CCE-B886-C0C171095CEF@oracle.com>
Message-ID: <f4b3afa6-644d-4813-b130-599b8c91ef3f@oracle.com>

Note that in terms of updating the implementation of toGenericString() 
JDK-8322878 to included sealed information, since strictfp is a no-op in 
the same release sealed/non-sealed was added, a class file can be

 ??? sealed XOR strictfp

Therefore, Class.toGenericString() could print the modifiers from 
getModifiers() and then add sealing information while retaining the 
blessed modifier order. In other words, the 
"Modifier.toString(modifiers)" code in Class.toGenericString() does not 
have to be "interrupted" to handle presenting sealed information in the 
blessed order.

HTH,

-Joe

On 1/2/2024 4:08 AM, Pavel Rappo wrote:
> I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
>
>      8.1.1. Class Modifiers
>      ...
>      
>      ClassModifier:
>      (one of)
>      Annotation public protected private
>      abstract static final sealed non-sealed strictfp
>      
>      ...
>
>      If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.
>
>
> Shall I just create a PR?
>
>> On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>
>> I couldn't find any prior discussions on this matter.
>>
>> I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are ordered differently. If we have a consensus on how to extend the "blessed order" onto those new keywords, I can create a PR to update the script.
>>
>> -Pavel
>>

From darcy at openjdk.org  Wed Jan  3 06:49:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Jan 2024 06:49:05 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
Message-ID: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>

As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.

This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

Commit messages:
 - JDK-8322878: Including sealing information Class.toGenericString()

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

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

From stefank at openjdk.org  Wed Jan  3 07:51:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 07:51:53 GMT
Subject: Integrated: 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: <4TnvCS-vkmkq_e4M78Qb-6ROT-YubrleoCy5-O0um2Q=.fca30dfe-fac2-46a6-8b3d-57b39c2e62c0@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...

This pull request has now been integrated.

Changeset: 9ab29f8d
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ab29f8dcd1c0092e4251f996bd53c704e87a74a
Stats:     61 lines in 3 files changed: 47 ins; 11 del; 3 mod

8321718: ProcessTools.executeProcess calls waitFor before logging

Reviewed-by: dholmes, jpai

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

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

From stefank at openjdk.org  Wed Jan  3 07:55:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 07:55:12 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v5]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <GpEb2qpnxJqXX5Ogimr2sbaXPOyFbB7wh06f0a47vc8=.96bd91bf-8487-49e0-8112-77843e7e3b15@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/486dc6d5..755d925d

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

  Stats: 875 lines in 70 files changed: 577 ins; 58 del; 240 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  Wed Jan  3 08:55:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 08:55:54 GMT
Subject: Integrated: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <97p3loy_9ZZnMenWO0FMfeACOTWUjesg8dVD6fmYCzs=.160baa3e-3709-4ece-a3aa-986206b73148@github.com>

On Mon, 11 Dec 2023 09:15:50 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.

This pull request has now been integrated.

Changeset: cbe329b9
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbe329b90ac1488836d4852fead79aa26c082114
Stats:     262 lines in 89 files changed: 73 ins; 1 del; 188 mod

8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

Reviewed-by: lkorinth, lmesnik

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

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

From shade at openjdk.org  Wed Jan  3 09:13:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Jan 2024 09:13:47 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <5ALWCoXpHaHo3RKUZq_VQeY-oAQqGGcP_L_Blw5FI8U=.355901b0-2005-4887-9aa7-718b5b956573@github.com>

On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao <duke at openjdk.org> wrote:

> 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%.

We need @DougLea to take a look :)

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

PR Comment: https://git.openjdk.org/jdk/pull/17116#issuecomment-1875046493

From jpai at openjdk.org  Wed Jan  3 09:29:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 09:29:48 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
In-Reply-To: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
Message-ID: <V9X71CnvsO4mEXsThlMw2gEd1qJ2E67wBCdqvU3pma8=.0f7fa58a-bb8e-49bc-ac81-78e227d84441@github.com>

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.

Hello Alan,

> > I guess that then means that the some pinned threads might not even appear in this generated thread dumps.
> 
> Just to be clear. The changes here have no impact on thread dumps, the thread dump generated by jcmd Thread.dump_to_file has all virtual threads, including pinned threads.

I didn't word my previous comment correctly. As you say, the `jdk.tracePinnedThreads` system property doesn't play a role in the thread dumps that generated through the jcmd command. This  system property just enables auto generation of a thread dump of a virtual thread when that virtual thread gets pinned. That thread dump logging happens from within that virtual thread, which is what I understand to be the reason behind the potential hang.

My understanding is that the `jcmd Thread.dump_to_file` command, when invoked, does the thread dump generation (for all threads) from within the Attach Listener thread which is a platform thread and thus isn't susceptible to this issue of hanging. 

> 
> As regards jdk.tracePinnedThreads. We want this system property to go away, it's just unfortunate that it seems to be widely used.

I think it was the ease of use (unlike having to start JFR recording) and the "event driven" automated thread dump (it gets logged only when the virtual thread is pinned unlike having to manually generate thread dumps) which made it attractive, especially during the early testing of virtual threads with other parts of the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/17221#issuecomment-1875066674

From jpai at openjdk.org  Wed Jan  3 09:46:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 09:46:46 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
In-Reply-To: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
Message-ID: <DAJWqJEu5tvdjIZ22taABL-kj5PUPvkPIV6WmXn6hO4=.347ada47-da16-4e85-824f-0e5ccdacaf6b@github.com>

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.

Overall this change looks OK to me. I'm not too familiar with the (virtual) thread states so I can't say if there's any other implication of changing the virtual thread state to RUNNING when we are printing this thread dump.

I've a trivial review comment about the new test method introduced in this PR, which I have added inline.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17221#pullrequestreview-1801666856

From jpai at openjdk.org  Wed Jan  3 09:50:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 09:50:47 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
In-Reply-To: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
Message-ID: <_f11V_viDBDyUXtUHkmvuSuf9-q7uLqsR1MsCWk1bDw=.198af18e-d82e-47b3-93a7-2a20863cc0a5@github.com>

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.

test/jdk/java/lang/Thread/virtual/TracePinnedThreads.java line 105:

> 103:      */
> 104:     @Test
> 105:     void testContention() throws Exception {

I think this test method  expects to have all the launched threads to print to System.out without hanging. If it hangs then we expect the test run to timeout with a jtreg timeout. Given the context of this PR in which this test method is being introduced, I think I can understand what it does. But maybe we should update the test method's comment to say that this method verifies that contention when writing to System.out when pinned doesn't cause any hangs?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17221#discussion_r1440252673

From stefank at openjdk.org  Wed Jan  3 09:55:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 09:55:54 GMT
Subject: RFR: 8322920: Some executeProcess overloads are declared to throw
 Throwable
Message-ID: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>

Most functions in ProcessTools are declared to throw Exceptions, or one of its subclasses. However, there are a small number of functions that are unnecessarily declared to throw Throwable instead of Exception. I propose that we change them to also be declared to throw Exception.

This is a trivial patch to make it easier to refactor tests to use the updated functions.

Tested manually, but will wait for GHA to verify that the change is OK.

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

Commit messages:
 - 8322920: Some executeProcess overloads are declared to throw Throwable

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

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

From alanb at openjdk.org  Wed Jan  3 11:14:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 11:14:49 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
Message-ID: <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>

On Wed, 13 Dec 2023 22:20:55 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 incrementally with one additional commit since the last revision:
> 
>   add select timeout field to the event

src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 143:

> 141:         throws IOException
> 142:     {
> 143:         // filter selectNow ops from consideration (timeout == 0)

I think simplify this comment to say no JFR event for selectNow.

src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 153:

> 151:         if ((n == 0) || (SelectorSelectEvent.shouldCommit(duration))) {
> 152:             timeout = (timeout < 0) ? 0 : timeout;
> 153:             SelectorSelectEvent.commit(start, duration, n, timeout);

The comment is a bit confusing here.  n == 0 means that no selected keys were added or consumed before timeout or wakeup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1440332584
PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1440332569

From jpai at openjdk.org  Wed Jan  3 11:41:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 11:41:39 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
Message-ID: <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>

On Tue, 2 Jan 2024 15:22:05 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.
>
> 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:
> 
>  - Revert changes to TracePinnedThreads.java
>  - Sync up from loom repo
>  - Merge
>  - Initial commit

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 29:

> 27:  * @requires vm.continuations
> 28:  * @requires !vm.debug | vm.gc != "Z"
> 29:  * @run main/othervm/timeout=300 -Xmx1500m Skynet

Are these heap sizing changes to reduce the resource usage of this test or is it to try and trigger any potential issue that this test verifies?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17136#discussion_r1440354141

From mbaesken at openjdk.org  Wed Jan  3 11:47:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 11:47:54 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class
 name "java.util.Arrays"
Message-ID: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>

In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

Commit messages:
 - JDK-8322782

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

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

From asotona at openjdk.org  Wed Jan  3 11:52:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Jan 2024 11:52:51 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v6]
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: <QIV0g40WT5pxhGKFlXVqhAWloasdm1ca_akSkfehn7s=.ac1efee5-cc94-4ca4-94d2-7e3a624f370d@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:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/41e87934..c8f1d304

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Jan  3 11:52:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Jan 2024 11:52:52 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <E98eLURLO5V9RD5LBvvi9hxgS9v64sojZEarTCawtuk=.1a0e510e-6bdd-4b54-8040-10e2a1712cbc@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>
 <E98eLURLO5V9RD5LBvvi9hxgS9v64sojZEarTCawtuk=.1a0e510e-6bdd-4b54-8040-10e2a1712cbc@github.com>
Message-ID: <4Cq83-fp7i_3iH6odBO-nv4ER5GVZfsoTPL-oXdaLTc=.7ff5a4dc-bba9-4931-9b3d-98755208694f@github.com>

On Sun, 24 Dec 2023 04:07:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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)

These changes are based on profiling of the benchmarks.
StackCounter was not used in any performance critical applications and profiling revealed some obvious bottlenecks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1440364580

From jpai at openjdk.org  Wed Jan  3 11:56:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 11:56:38 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
Message-ID: <k36AHGzZN2KBYXDtnAc8eqIld_VHXKG3-sP_gkjbgIU=.6f08593b-a9df-42de-a288-9ba584446921@github.com>

On Tue, 2 Jan 2024 15:22:05 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.
>
> 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:
> 
>  - Revert changes to TracePinnedThreads.java
>  - Sync up from loom repo
>  - Merge
>  - Initial commit

Overall these changes look OK to me. I haven't paid much attention to the jvmti test change, but I've looked at others and they seem fine.
The `StressStackOverflow` test has its duration reduced by half which appears intentional and then there's a new test library helper class to allow pinning tasks in tests.

Just one question - doesn't the use of a new native code in the test library (the `libVThreadPinner.c`) require any build changes (I'm not too familiar with that part)?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17136#pullrequestreview-1801861084

From alanb at openjdk.org  Wed Jan  3 11:56:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 11:56:41 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
 <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>
Message-ID: <M-kwswRy4ECQvr0Orv5j28k_yRbpWmeJir4XWXBrJK0=.49c21927-f991-45c6-9a62-97982bc8fe11@github.com>

On Wed, 3 Jan 2024 11:39:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Are these heap sizing changes to reduce the resource usage of this test or is it to try and trigger any potential issue that this test verifies?

The heap usage for this one can vary quite a bit, some of the lower optimization modes lead to more contention so there are are more FJP submissions. See JDK-8303635 for one example. It's been bumped to 1.5g in the loom repo for some time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17136#discussion_r1440368527

From alanb at openjdk.org  Wed Jan  3 11:59:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 11:59:46 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <k36AHGzZN2KBYXDtnAc8eqIld_VHXKG3-sP_gkjbgIU=.6f08593b-a9df-42de-a288-9ba584446921@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
 <k36AHGzZN2KBYXDtnAc8eqIld_VHXKG3-sP_gkjbgIU=.6f08593b-a9df-42de-a288-9ba584446921@github.com>
Message-ID: <BmDx2DMZiHb_29Mt5yVe0CpqTr_EVVAQ_8PQcscW0fo=.8312ce73-b057-4f7c-a626-0dbba592c3dc@github.com>

On Wed, 3 Jan 2024 11:53:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Just one question - doesn't the use of a new native code in the test library (the `libVThreadPinner.c`) require any build changes (I'm not too familiar with that part)?

Magnus did some work in the make files some time ago to build native libs in the test/lib tree.

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

PR Comment: https://git.openjdk.org/jdk/pull/17136#issuecomment-1875259504

From jpai at openjdk.org  Wed Jan  3 11:59:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 11:59:48 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <M-kwswRy4ECQvr0Orv5j28k_yRbpWmeJir4XWXBrJK0=.49c21927-f991-45c6-9a62-97982bc8fe11@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
 <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>
 <M-kwswRy4ECQvr0Orv5j28k_yRbpWmeJir4XWXBrJK0=.49c21927-f991-45c6-9a62-97982bc8fe11@github.com>
Message-ID: <KMutveIAyJKU8xcIlkS9Q_UlcD8KInHaij7q198VUWI=.2ecb7c51-6410-4b16-a161-0a31c0ad92d7@github.com>

On Wed, 3 Jan 2024 11:53:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  It's been bumped to 1.5g in the loom repo for some time.

Ah, I misread that change previously as reducing it from `1g` to `150m`, while infact this change is increasing it to `1500m`. Given your reference to JDK-8303635, the change looks OK to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17136#discussion_r1440371281

From dholmes at openjdk.org  Wed Jan  3 12:22:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Jan 2024 12:22:37 GMT
Subject: RFR: 8322920: Some ProcessTools.execute* functions are declared to
 throw Throwable
In-Reply-To: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
References: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
Message-ID: <OskMnEOZgfpIIhrRCTvZqI_SvIwZxgpQLvxWmgv9GO0=.3a14e83c-48b9-4dcf-ab27-f38e35250afc@github.com>

On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Most functions in ProcessTools are declared to throw Exceptions, or one of its subclasses. However, there are a small number of functions that are unnecessarily declared to throw Throwable instead of Exception. I propose that we change them to also be declared to throw Exception.
> 
> This is a trivial patch to make it easier to refactor tests to use the updated functions.
> 
> Tested manually, but will wait for GHA to verify that the change is OK.

Seems fine and trivial. As long as this compiles it is correct.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17240#pullrequestreview-1801895740

From asotona at openjdk.org  Wed Jan  3 12:28:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Jan 2024 12:28:49 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <6QJXbG4RyTpE8Xnbsr1NNTuAqokhgKbgbERN6t2VJso=.de1c67b9-8755-4b25-9f85-c92455ff12eb@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
 <6QJXbG4RyTpE8Xnbsr1NNTuAqokhgKbgbERN6t2VJso=.de1c67b9-8755-4b25-9f85-c92455ff12eb@github.com>
Message-ID: <oz1PEeqMI3xBLfqln3xOV5vILlYQncMe4ZjZWKhwSTM=.3eef4529-81e4-49d4-bd2a-1c30f7338054@github.com>

On Sun, 24 Dec 2023 03:14:44 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/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.

Original code has been significant in profiler.


MethodTypeDesc desc = MethodTypeDesc.of(toClassDesc(returnType),
                    Arrays.stream(parameterTypes).map(ProxyGenerator::toClassDesc).toArray(ClassDesc[]::new));


1. each `toClassDesc` builds `descriptorString` and parses/validates it while constructing `ClassDesc`
2. `Arrays.stream(...).map(...).toArray(...)` allocates an array
3. `MethodTypeDesc.of(...)` clones the array and iterates params to check for void
4. `desc.descriptorString()` then finally use the `StringJoiner` 

Optimized code only joins `descriptorString`, no validations, no streaming, no arrays, no cloning.


I suggest this patch as this code is considered as performance critical.
However we can go through `ClassDesc` and `MethodTypeDesc` if not performance critical or if the conversions would be optimized.

For example better (trusted) paths from `MethodType` to `MethodTypeDescriptor` and from `Class` to `ClassDesc`, avoiding at least validations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1440395021

From asotona at openjdk.org  Wed Jan  3 12:36:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Jan 2024 12:36:26 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
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: <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@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:

  StackCounter fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/c8f1d304..c6b761a1

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 alanb at openjdk.org  Wed Jan  3 13:32:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 13:32:38 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays"
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <9oRf6_NeT3KKnkiZNAwUlcK6kBs13ahenPR1iWFfcb8=.ed953023-01bb-45d0-858e-daf5d4d52093@github.com>

On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

Looks fine, surprised to see so many. I assume you'll bump the copyright date on all the files before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802064657

From mbaesken at openjdk.org  Wed Jan  3 13:51:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 13:51:03 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v2]
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <7MyzckmpbHdkVKO-GM7_sEkpOtRCN7wf2dBe50P7ptE=.8764e79c-d68b-4737-a906-31dadf47c140@github.com>

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

  adjust copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17241/files
  - new: https://git.openjdk.org/jdk/pull/17241/files/af1c0375..c06f35b5

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

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

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

From dl at openjdk.org  Wed Jan  3 13:54:46 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 3 Jan 2024 13:54:46 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <HnD0rYJ1rVu3w6dvBk95glPAfV1Ssb_DLm_5fGW7jvg=.50964d52-87a1-43d3-965f-ccced4d05e5c@github.com>

On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao <duke at openjdk.org> wrote:

> 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%.

Looks OK. It was just an oversight not to check for presizing here. Thanks for doing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17116#issuecomment-1875403205

From mbaesken at openjdk.org  Wed Jan  3 13:55:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 13:55:22 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

  Adjust Invokers.java too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17241/files
  - new: https://git.openjdk.org/jdk/pull/17241/files/c06f35b5..eac9ca69

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

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

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

From duke at openjdk.org  Wed Jan  3 13:57:59 2024
From: duke at openjdk.org (Thomas Wuerthinger)
Date: Wed, 3 Jan 2024 13:57:59 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@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>
 <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@github.com>
Message-ID: <zQ-YIzVMo-KlUmRNeMx-L7qd-kdXhDnX5PlSBUssJcM=.053967c3-f4b4-4b13-937c-51380e901399@github.com>

On Wed, 20 Dec 2023 10:40:23 GMT, Serguei Spitsyn <sspitsyn 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.
>
> Good catch, David!
> Filed a cleanup bug: https://bugs.openjdk.org/browse/JDK-8322538

Are these new compiler intrinsics required or an optional performance optimization? This PR creates issues for us when updating the JDK build for Graal. CC @davleopo

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1440478960

From alanb at openjdk.org  Wed Jan  3 14:06:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 14:06:53 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <zQ-YIzVMo-KlUmRNeMx-L7qd-kdXhDnX5PlSBUssJcM=.053967c3-f4b4-4b13-937c-51380e901399@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>
 <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@github.com>
 <zQ-YIzVMo-KlUmRNeMx-L7qd-kdXhDnX5PlSBUssJcM=.053967c3-f4b4-4b13-937c-51380e901399@github.com>
Message-ID: <av4HwfBaHRjBgTfIRw6riJEcMcqGY3R5wOYwNyEmbpI=.975ca00d-050d-4855-a4d3-85e9b39f1a5f@github.com>

On Wed, 3 Jan 2024 13:55:24 GMT, Thomas Wuerthinger <duke at openjdk.org> wrote:

> Are these new compiler intrinsics required or an optional performance optimization? 

Performance. If the intrinsic isn't there then some methods executed on virtual threads, or on a virtual thread as the target for some op, will have to call into the VM.  The main concern was Thread.interrupted() as it gets called very frequently in locking and concurrency code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1440487675

From mbaesken at openjdk.org  Wed Jan  3 14:04:48 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 14:04:48 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <DT_MWVwT-RJ-7yBvvVC7b1g5Ydzaieys5v3KReYzyI4=.ba3f0f55-faf2-4988-bb39-4d8539ca075a@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Hi Alan, thanks for the review !
I adjust the copyright year info and also some more places in Invokers.java .

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

PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1875416193

From shade at openjdk.org  Wed Jan  3 14:37:48 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Jan 2024 14:37:48 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <6KHFpU9XhtrxqNjMjx_vQnt4m3qYCn9p2ROR2nXvaVY=.3aabfb7f-c523-4ed6-96c8-829450149fbf@github.com>

On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao <duke at openjdk.org> wrote:

> 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%.

All right, good! I have comments about the benchmark:

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 851:

> 849:      */
> 850:     public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
> 851:         this(m.size(), LOAD_FACTOR, 1);

This looks like just `this(m.size())`, right? Not sure if we want to save an additional chained constructor call, though.

test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 83:

> 81:         for (int i = 0; i < nkeys; ++i) {
> 82:             staticMap.put(rng.next(), rng.next());
> 83:         }

Can just merge this loop with the one above, reusing `rng.next()` for both key and values for `staticMap`.

test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:

> 120:     public void testCopyConstructor() {
> 121:         ConcurrentHashMap<Integer, Integer> clone = new ConcurrentHashMap<>(staticMap);
> 122:         dummy = clone;

Is this for preventing dead-code elimination? If so, just do:


  return new ConcurrentHashMap<>(staticMap);

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

PR Review: https://git.openjdk.org/jdk/pull/17116#pullrequestreview-1802240545
PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1440523638
PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1440517305
PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1440515260

From alanb at openjdk.org  Wed Jan  3 15:01:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 15:01:50 GMT
Subject: Integrated: 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: <MXBZKESEZF9KtNaei_9342CBwUfRTVqc5JBp1qGSfxM=.93062578-7619-4ceb-8f7c-79464251bd5f@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.

This pull request has now been integrated.

Changeset: b67b71cd
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b67b71cd87c62f15d5b73f923c300d0f77c988f5
Stats:     981 lines in 16 files changed: 618 ins; 213 del; 150 mod

8320707: Virtual thread test updates

Reviewed-by: jpai

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

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

From rriggs at openjdk.org  Wed Jan  3 15:02:39 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 Jan 2024 15:02:39 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>

On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

LGTM

src/java.base/share/classes/java/lang/Class.java line 264:

> 262:     /**
> 263:      * Returns a string describing this {@code Class}, including
> 264:      * information about modifiers, {@linkplain #isSealed() sealing}, and type parameters.

If Class.toGenericString is a useful API point for describing the blessed order of modifiers in the JDK
perhaps the existing classes that describe modifiers could/should cross reference this method.

src/java.base/share/classes/java/lang/Class.java line 320:

> 318:                 // sufficient to check for sealed-ness after all
> 319:                 // modifiers are printed.
> 320:                 boolean isSealed = isSealed();

A small concern about performance.  
Class.isSealed() calls getPermittedSubclasses() which assembles and filters the list of classes and a possible security manager check and then only checks for non-null.
Perhaps a separate issue could look at that.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17239#pullrequestreview-1802318323
PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440551717
PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440543767

From prappo at openjdk.org  Wed Jan  3 16:43:47 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 3 Jan 2024 16:43:47 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
Message-ID: <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>

On Wed, 3 Jan 2024 14:59:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
>> 
>> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.
>
> src/java.base/share/classes/java/lang/Class.java line 264:
> 
>> 262:     /**
>> 263:      * Returns a string describing this {@code Class}, including
>> 264:      * information about modifiers, {@linkplain #isSealed() sealing}, and type parameters.
> 
> If Class.toGenericString is a useful API point for describing the blessed order of modifiers in the JDK
> perhaps the existing classes that describe modifiers could/should cross reference this method.

Given potential lossiness of source modifiers presentation by java.lang.reflect, I don't think this method is a good host for describing the canonical modifier order. Mentioning? Probably. Describing? No.

Separately, but also related: while it does not seem impossible, this PR does not implement `non-sealed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440663061

From aivanov at openjdk.org  Wed Jan  3 16:53:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 3 Jan 2024 16:53:47 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <B4b8hcwJuDZ13_YT-Z3AmKful6e8fkxL1GkjF33HcuA=.0923da91-b9f8-4f70-8261-408d7db28edc@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802684965

From dcubed at openjdk.org  Wed Jan  3 17:21:14 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 3 Jan 2024 17:21:14 GMT
Subject: Integrated: 8322963: ProblemList
 java/io/BufferedInputStream/TransferTo.java
In-Reply-To: <V4P4Cdu1h08N8AmDB0IGW6Hs_PGOWq8N1wX62cBEjLU=.16577ca1-9620-47ac-b9cb-72ba42c2d044@github.com>
References: <BL4uI_e1CLG0fY2flsJcvr1hquPYRU5Dm36L_zP9M6I=.68920d14-bef8-4f0a-81c9-228b4891e112@github.com>
 <V4P4Cdu1h08N8AmDB0IGW6Hs_PGOWq8N1wX62cBEjLU=.16577ca1-9620-47ac-b9cb-72ba42c2d044@github.com>
Message-ID: <5NSU8nepWuWD1cVSWQGeHOCx0GsvUBlLuKD468e72ZM=.085aa582-5953-4479-af4d-1c8e180f198c@github.com>

On Wed, 3 Jan 2024 17:14:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the lightning fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17249#issuecomment-1875706401

From dcubed at openjdk.org  Wed Jan  3 17:21:15 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 3 Jan 2024 17:21:15 GMT
Subject: Integrated: 8322963: ProblemList
 java/io/BufferedInputStream/TransferTo.java
In-Reply-To: <BL4uI_e1CLG0fY2flsJcvr1hquPYRU5Dm36L_zP9M6I=.68920d14-bef8-4f0a-81c9-228b4891e112@github.com>
References: <BL4uI_e1CLG0fY2flsJcvr1hquPYRU5Dm36L_zP9M6I=.68920d14-bef8-4f0a-81c9-228b4891e112@github.com>
Message-ID: <Yij3S7ntGHnNPC7_TepTKu3zmxElK-cr8smdVXOHXXA=.0bf532ae-3abb-436e-9a10-89625797f9f7@github.com>

On Wed, 3 Jan 2024 17:13:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java.

This pull request has now been integrated.

Changeset: cc9ab5f1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc9ab5f1976486f0a4a681e01b1a8ac36e7c6f29
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8322963: ProblemList java/io/BufferedInputStream/TransferTo.java

Reviewed-by: bpb

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

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

From bpb at openjdk.org  Wed Jan  3 17:21:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Jan 2024 17:21:14 GMT
Subject: Integrated: 8322963: ProblemList
 java/io/BufferedInputStream/TransferTo.java
In-Reply-To: <BL4uI_e1CLG0fY2flsJcvr1hquPYRU5Dm36L_zP9M6I=.68920d14-bef8-4f0a-81c9-228b4891e112@github.com>
References: <BL4uI_e1CLG0fY2flsJcvr1hquPYRU5Dm36L_zP9M6I=.68920d14-bef8-4f0a-81c9-228b4891e112@github.com>
Message-ID: <V4P4Cdu1h08N8AmDB0IGW6Hs_PGOWq8N1wX62cBEjLU=.16577ca1-9620-47ac-b9cb-72ba42c2d044@github.com>

On Wed, 3 Jan 2024 17:13:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17249#pullrequestreview-1802749494

From dcubed at openjdk.org  Wed Jan  3 17:21:14 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 3 Jan 2024 17:21:14 GMT
Subject: Integrated: 8322963: ProblemList
 java/io/BufferedInputStream/TransferTo.java
Message-ID: <BL4uI_e1CLG0fY2flsJcvr1hquPYRU5Dm36L_zP9M6I=.68920d14-bef8-4f0a-81c9-228b4891e112@github.com>

A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java.

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

Commit messages:
 - 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java

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

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

From pchilanomate at openjdk.org  Wed Jan  3 17:29:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Jan 2024 17:29:46 GMT
Subject: RFR: 8322818: Thread::getStackTrace can fail with InternalError if
 virtual thread is timed-parked when pinned
In-Reply-To: <dRXi6Od3v6dYcDt1vTjQBzJ-CyJL_EU9d0YYhiIDMiE=.4552f5e0-b8bc-4e23-82be-19fbd70ee65f@github.com>
References: <dRXi6Od3v6dYcDt1vTjQBzJ-CyJL_EU9d0YYhiIDMiE=.4552f5e0-b8bc-4e23-82be-19fbd70ee65f@github.com>
Message-ID: <Gx68u67kqroKQl4jjS-TMIhJOYFIeHBqQciMZL6Z-cc=.82a02479-33d5-49fe-b9b9-61c43dd0e715@github.com>

On Tue, 2 Jan 2024 08:55:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Missed by JDK-8312498, VirtualThread::tryGetStackTrace doesn't handle the TIMED_PINNED state so it's possible for Thread::getStackTrace to throw InternalError when invoked on a virtual thread that quickly transitions from unmounted to  timed-park-while-pinned. This one is needs a stress test to reproduce.

Looks good to me.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17217#pullrequestreview-1802781750

From bpb at openjdk.org  Wed Jan  3 18:07:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Jan 2024 18:07:53 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
Message-ID: <1K2bfsIhW_XJF4w4jq9NUO0In9AobhrWENLUYYG8lgc=.611c4b38-2956-4ec0-b157-6336e30efa94@github.com>

On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.

Everyone was apparently caught off guard as previously `Arrays.copyOfRange(byte[],int,int)` had been used here, and its third parameter is the `to` position, not the number of bytes to copy.

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

PR Comment: https://git.openjdk.org/jdk/pull/17250#issuecomment-1875761630

From bpb at openjdk.org  Wed Jan  3 18:07:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Jan 2024 18:07:53 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed with
 IndexOutOfBoundsException
Message-ID: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>

The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.

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

Commit messages:
 - 8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

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

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

From darcy at openjdk.org  Wed Jan  3 18:12:47 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Jan 2024 18:12:47 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
Message-ID: <r1mccUXz5BE86XVTSu_3toAvWe6DOYTMdYL6nVykXDc=.3f9ef740-84a1-4242-84c5-b855c3d909bf@github.com>

On Wed, 3 Jan 2024 14:52:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
>> 
>> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.
>
> src/java.base/share/classes/java/lang/Class.java line 320:
> 
>> 318:                 // sufficient to check for sealed-ness after all
>> 319:                 // modifiers are printed.
>> 320:                 boolean isSealed = isSealed();
> 
> A small concern about performance.  
> Class.isSealed() calls getPermittedSubclasses() which assembles and filters the list of classes and a possible security manager check and then only checks for non-null.
> Perhaps a separate issue could look at that.

If Class.toGenericString() turned out to be performance sensitive, which would be a surprise, then we could look into alternate implementations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440757367

From alanb at openjdk.org  Wed Jan  3 18:13:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 18:13:46 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
Message-ID: <RgXPcB-raxknQFKR29C58vHTvGTHf3BOKQFU2UhzC94=.3b0021e5-8bac-43f5-b83c-908ea73e7e93@github.com>

On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17250#pullrequestreview-1802848600

From darcy at openjdk.org  Wed Jan  3 18:18:48 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Jan 2024 18:18:48 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
 <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
Message-ID: <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>

On Wed, 3 Jan 2024 16:40:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 264:
>> 
>>> 262:     /**
>>> 263:      * Returns a string describing this {@code Class}, including
>>> 264:      * information about modifiers, {@linkplain #isSealed() sealing}, and type parameters.
>> 
>> If Class.toGenericString is a useful API point for describing the blessed order of modifiers in the JDK
>> perhaps the existing classes that describe modifiers could/should cross reference this method.
>
> Given potential lossiness of source modifiers presentation by java.lang.reflect, I don't think this method is a good host for describing the canonical modifier order. Mentioning? Probably. Describing? No.
> 
> Separately, but also related: while it does not seem impossible, this PR does not implement `non-sealed`.

I think the best place, or least-bad place, to discuss the "modifier" ordering of sealed/non-sealed would be an informative note on Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are not represented in the class file as access flags and thus not modeled by this class [java.lang.reflect.Modifier] .... sealed/non-sealed should be presented in the same location as final."

Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440765048

From darcy at openjdk.org  Wed Jan  3 18:38:47 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Jan 2024 18:38:47 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <Y-mN5jR9VQrvR_PfvNOinEU9sEiYzJYUaBxQg1D5VcI=.762c61e8-efd5-44ba-a546-6ca68dddffc4@github.com>

On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

As the output of toGenericString does not attempt to fully capture the full declaration information of a class or interfaces, omitted any extends or implementation information for example, I think it is fine to also omit any listed of permitted subtypes for a sealed class or interface. This sidesteps design issues around which permitted subtypes should be filtered out for display purposes, etc.

CSR up for review: https://bugs.openjdk.org/browse/JDK-8322969
TIA

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

PR Comment: https://git.openjdk.org/jdk/pull/17239#issuecomment-1875783748
PR Comment: https://git.openjdk.org/jdk/pull/17239#issuecomment-1875794166

From joehw at openjdk.org  Wed Jan  3 19:38:03 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 3 Jan 2024 19:38:03 GMT
Subject: RFR: 8322214: Return value of XMLInputFactory.getProperty() changed
 from boolean to String in JDK 22 early access builds
Message-ID: <YsSLbB-_MXD6vOpirDYiLPXI2RYS4vgFUy3KqKwoJpg=.a18fce9f-42ba-4fc3-8f74-896eb8438a1a@github.com>

Fix the get (return) operation by using the same method as that used for checking the values of the DTD features during the resolution process.

Note: this patch also addresses the issue reported in https://bugs.openjdk.org/browse/JDK-8322216

Test: new test added covers DTD properties for SAX/DOM/StAX.
         Existing tests passed.

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

Commit messages:
 - 8322214: Return value of XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early access builds

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

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

From prappo at openjdk.org  Wed Jan  3 19:47:23 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 3 Jan 2024 19:47:23 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
 <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
 <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>
Message-ID: <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>

On Wed, 3 Jan 2024 18:16:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)

Naively, I thought that something like this is possible _in principle_; I might be mistaken though:

diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java
index 851d65d06ad..014845860d0 100644
--- a/src/java.base/share/classes/java/lang/Class.java
+++ b/src/java.base/share/classes/java/lang/Class.java
@@ -4771,6 +4771,30 @@ public boolean isSealed() {
         return getPermittedSubclasses() != null;
     }
 
+    private boolean isNonSealed() {
+        if (isSealed())
+            return false;
+        if (!isInterface() && Modifier.isFinal(getModifiers())) {
+            // unlike interface, class can be final
+            return false;
+        }
+        // if an ancestor is sealed, this class can either be non-sealed or final
+        return hasSealedAncestor(this);
+    }
+
+    private boolean hasSealedAncestor(Class<?> clazz) {
+        var superclass = clazz.getSuperclass();
+        if (superclass != null) {
+            if (superclass.isSealed() || hasSealedAncestor(superclass))
+                return true;
+        }
+        for (var superinterface : clazz.getInterfaces()) {
+            if (superinterface.isSealed() || hasSealedAncestor(superinterface))
+                return true;
+        }
+        return false;
+    }
+
     private native Class<?>[] getPermittedSubclasses0();
 
     /*

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440867004

From stsypanov at openjdk.org  Wed Jan  3 19:52:20 2024
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 3 Jan 2024 19:52:20 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
Message-ID: <k_pH1tkVgkNz7x_ehvt3qIJJb9hmMQgXHPqTtthW-04=.fc3d7edc-4d31-49a8-9a54-ed2ae2bb863e@github.com>

On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.

Marked as reviewed by stsypanov (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/17250#pullrequestreview-1802977250

From duke at openjdk.org  Wed Jan  3 19:55:23 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 3 Jan 2024 19:55:23 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing
In-Reply-To: <6KHFpU9XhtrxqNjMjx_vQnt4m3qYCn9p2ROR2nXvaVY=.3aabfb7f-c523-4ed6-96c8-829450149fbf@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <6KHFpU9XhtrxqNjMjx_vQnt4m3qYCn9p2ROR2nXvaVY=.3aabfb7f-c523-4ed6-96c8-829450149fbf@github.com>
Message-ID: <RE2pbkG5xL9GPHjBNGF3rgpyIb_HHutRbfGvqEhJI08=.864035fa-39c0-488d-998d-5f515ed72a9b@github.com>

On Wed, 3 Jan 2024 14:34:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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%.
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 851:
> 
>> 849:      */
>> 850:     public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
>> 851:         this(m.size(), LOAD_FACTOR, 1);
> 
> This looks like just `this(m.size())`, right? Not sure if we want to save an additional chained constructor call, though.

Yep, same thing. I'll change it.

> test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:
> 
>> 120:     public void testCopyConstructor() {
>> 121:         ConcurrentHashMap<Integer, Integer> clone = new ConcurrentHashMap<>(staticMap);
>> 122:         dummy = clone;
> 
> Is this for preventing dead-code elimination? If so, just do:
> 
> 
>   return new ConcurrentHashMap<>(staticMap);

I tried this. I don't think its working. When I just return the map, we lose the improvements in performance, and the benchmark overall just runs much faster. I'm guessing the map got DCE'ed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1440798729
PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1440875149

From duke at openjdk.org  Wed Jan  3 20:39:22 2024
From: duke at openjdk.org (jmehrens)
Date: Wed, 3 Jan 2024 20:39:22 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v6]
In-Reply-To: <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <FR8BSAikgxqhGe-_lkFNUI2TOQ4V-W1iNfptNe84CoE=.f501a415-2f10-4ae9-8ded-ffc02a02dd35@github.com>
 <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com>
Message-ID: <QfynfvBHCsW5azqDfHwnWYYQJVYLTpWIgXRgYo4LMEs=.34e1b6bc-7cc7-4098-930d-1c1564dd9ac4@github.com>

On Sat, 30 Dec 2023 20:51:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>I think this ticket should focus on adding the new constructor as part of the API.

Okay.  I would think the code would avoid heapify when the caller does foolish things with this API such as:

SortedSet ss = filledSortedSet();
PriorityQueue pq1 = new PriorityQueue(ss.comparator(), ss);

PriorityQueue pq = filledPriorityQueue();
PriorityQueue pq2 = new PriorityQueue(pq.comparator(), pq);


I assume this constructor is going to be added to TreeSet, PriorityBlockingQueue, and ConcurrentSkipListSet?

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

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1875939913

From duke at openjdk.org  Wed Jan  3 21:18:48 2024
From: duke at openjdk.org (Eric Murphy)
Date: Wed, 3 Jan 2024 21:18:48 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <V35SZ_vVNERPrlX1dYGItpPyqjCR7BDANiJ_qcAjkoA=.5dda8c32-b2af-46e3-8b4c-24cb59625d2d@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <Eedn97kCuEfSSTKaLbnkOWgYixVv3Ep5VTaXmcIKLaw=.a7b65202-b9ef-4629-8e2a-3f98bf9de4cf@github.com>
 <NAQkATnvy76vxCylJTHO2aJRlUwDvt20rSSbs83l5kA=.b84451ba-f064-4d39-a56d-f6766f5474ef@github.com>
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 <jhlTsgcmc7M1A9HwNoHm3wrLhdCmShtYOPQ1dXmuno0=.f5ae7b6e-4cda-4f6e-8b6f-3658c7bd91da@github.com>
 <pgLroOe8E7eOpVkGTFMgXjgMP9-NyWHpRwlW8uSfqvE=.a2bd8738-7526-4fb2-8d5b-0bc03a3d50c1@github.com>
 <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
 <V35SZ_vVNERPrlX1dYGItpPyqjCR7BDANiJ_qcAjkoA=.5dda8c32-b2af-46e3-8b4c-24cb59625d2d@github.com>
Message-ID: <OLyU_iKVX5hNTjojnkb6a4WzAEkxzu67rq250cPisRs=.5f8511a1-54aa-4a93-a0e7-b6ef4b3b8916@github.com>

On Sun, 15 Oct 2023 07:40:06 GMT, himichael <duke at openjdk.org> wrote:

> sing a physical machine, I am using a virtual machine, this virtual machine supports the AVX512 instruction set.
> How do I open libsimdsort ?

@himichael Did you ever resolve your issue? I am using JDK22 from SDKMan and have the same errors:


 java  -Xlog:library   
[0.013s][info][library] Loaded library libjsvml.so, handle 0x00007fc9a40229b0
[0.024s][info][library] Failed to find JNI_OnLoad_nio in library with handle 0x00007fca6b2dc220
[0.024s][info][library] Loaded library /home/eric/.sdkman/candidates/java/22.ea.29-open/lib/libnio.so, handle 0x00007fca6419b9b0
[0.024s][info][library] Found JNI_OnLoad in library with handle 0x00007fca6419b9b0
[0.024s][info][library] Found Java_sun_nio_fs_UnixNativeDispatcher_init in library with handle 0x00007fca6419b9b0
[0.024s][info][library] Found Java_sun_nio_fs_UnixNativeDispatcher_getcwd in library with handle 0x00007fca6419b9b0
[0.025s][info][library] Failed to find JNI_OnLoad_jimage in library with handle 0x00007fca6b2dc220
[0.025s][info][library] Loaded library /home/eric/.sdkman/candidates/java/22.ea.29-open/lib/libjimage.so, handle 0x00007fca64006380
[0.025s][info][library] Failed to find JNI_OnLoad in library with handle 0x00007fca64006380
[0.025s][info][library] Failed to find Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap in library with handle 0x00007fca6419b9b0
[0.025s][info][library] Found Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap in library with handle 0x00007fca64006380

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1875978761

From bpb at openjdk.org  Wed Jan  3 21:26:29 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Jan 2024 21:26:29 GMT
Subject: Integrated: 8322877: java/io/BufferedInputStream/TransferTo.java
 failed with IndexOutOfBoundsException
In-Reply-To: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
Message-ID: <2FfGyDCoTQBD7UpsMytEkfTGgwRysaG_RQrVSGZB8dM=.80396e6a-548f-4684-ac67-25ae78f1f878@github.com>

On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.

This pull request has now been integrated.

Changeset: 54b3ceec
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54b3ceeca27b67f4270d8b700b072f46959dba65
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

8322877: java/io/BufferedInputStream/TransferTo.java failed with IndexOutOfBoundsException

Reviewed-by: alanb, stsypanov

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

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

From duke at openjdk.org  Wed Jan  3 21:29:57 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 3 Jan 2024 21:29:57 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <RE2pbkG5xL9GPHjBNGF3rgpyIb_HHutRbfGvqEhJI08=.864035fa-39c0-488d-998d-5f515ed72a9b@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <6KHFpU9XhtrxqNjMjx_vQnt4m3qYCn9p2ROR2nXvaVY=.3aabfb7f-c523-4ed6-96c8-829450149fbf@github.com>
 <RE2pbkG5xL9GPHjBNGF3rgpyIb_HHutRbfGvqEhJI08=.864035fa-39c0-488d-998d-5f515ed72a9b@github.com>
Message-ID: <e9jLiQ_EIX1atXKZkqEaCPPWW4_gkKUhUFPmjsNZijc=.4f959405-f58d-4bac-8dd7-d27026292736@github.com>

On Wed, 3 Jan 2024 19:52:34 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:
>> 
>>> 120:     public void testCopyConstructor() {
>>> 121:         ConcurrentHashMap<Integer, Integer> clone = new ConcurrentHashMap<>(staticMap);
>>> 122:         dummy = clone;
>> 
>> Is this for preventing dead-code elimination? If so, just do:
>> 
>> 
>>   return new ConcurrentHashMap<>(staticMap);
>
> I tried this. I don't think its working. When I just return the map, we lose the improvements in performance, and the benchmark overall just runs much faster. I'm guessing the map got DCE'ed

Scratch that. Was my mistake. Was running the wrong test.

I'm renaming `testCopyConstructor` to `testConcurrentHashMapCopyConstructor`, since the file name + test don't actually explicitly say its for ConcurrentHashMap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1440968465

From duke at openjdk.org  Wed Jan  3 21:29:57 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 3 Jan 2024 21:29:57 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@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%.

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

  Cleanup benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17116/files
  - new: https://git.openjdk.org/jdk/pull/17116/files/93b9072d..3632649c

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

  Stats: 12 lines in 2 files changed: 2 ins; 7 del; 3 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 lancea at openjdk.org  Wed Jan  3 21:39:22 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 3 Jan 2024 21:39:22 GMT
Subject: RFR: 8322214: Return value of XMLInputFactory.getProperty()
 changed from boolean to String in JDK 22 early access builds
In-Reply-To: <YsSLbB-_MXD6vOpirDYiLPXI2RYS4vgFUy3KqKwoJpg=.a18fce9f-42ba-4fc3-8f74-896eb8438a1a@github.com>
References: <YsSLbB-_MXD6vOpirDYiLPXI2RYS4vgFUy3KqKwoJpg=.a18fce9f-42ba-4fc3-8f74-896eb8438a1a@github.com>
Message-ID: <ePfNK-HNJvKWMAmiuentvF7H0bDZNsqC7hSZ9N3Ulvw=.036f2fe2-112c-4c4e-a146-6a74bc6ea132@github.com>

On Wed, 3 Jan 2024 19:31:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix the get (return) operation by using the same method as that used for checking the values of the DTD features during the resolution process.
> 
> Note: this patch also addresses the issue reported in https://bugs.openjdk.org/browse/JDK-8322216
> 
> Test: new test added covers DTD properties for SAX/DOM/StAX.
>          Existing tests passed.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17252#pullrequestreview-1803102547

From darcy at openjdk.org  Wed Jan  3 22:23:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Jan 2024 22:23:21 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
 <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
 <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>
 <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>
Message-ID: <1uO8XMaqipFMM0s9VoxjdVheA4fidEaglMKSg8yjRYw=.ff42d280-8742-43ee-97cb-b4bb3ab6619d@github.com>

On Wed, 3 Jan 2024 19:44:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I think the best place, or least-bad place, to discuss the "modifier" ordering of sealed/non-sealed would be an informative note on Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are not represented in the class file as access flags and thus not modeled by this class [java.lang.reflect.Modifier] .... sealed/non-sealed should be presented in the same location as final."
>> 
>> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)
>
>> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)
> 
> Naively, I thought that something like this is possible _in principle_; I might be mistaken though:
> 
> diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java
> index 851d65d06ad..014845860d0 100644
> --- a/src/java.base/share/classes/java/lang/Class.java
> +++ b/src/java.base/share/classes/java/lang/Class.java
> @@ -4771,6 +4771,30 @@ public boolean isSealed() {
>          return getPermittedSubclasses() != null;
>      }
>  
> +    private boolean isNonSealed() {
> +        if (isSealed())
> +            return false;
> +        if (!isInterface() && Modifier.isFinal(getModifiers())) {
> +            // unlike interface, class can be final
> +            return false;
> +        }
> +        // if an ancestor is sealed, this class can either be non-sealed or final
> +        return hasSealedAncestor(this);
> +    }
> +
> +    private boolean hasSealedAncestor(Class<?> clazz) {
> +        var superclass = clazz.getSuperclass();
> +        if (superclass != null) {
> +            if (superclass.isSealed() || hasSealedAncestor(superclass))
> +                return true;
> +        }
> +        for (var superinterface : clazz.getInterfaces()) {
> +            if (superinterface.isSealed() || hasSealedAncestor(superinterface))
> +                return true;
> +        }
> +        return false;
> +    }
> +
>      private native Class<?>[] getPermittedSubclasses0();
>  
>      /*

Thanks @pavelrappo; I'll explore incorporating functionality like this into the PR, probably next week.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1441020362

From darcy at openjdk.org  Wed Jan  3 22:42:20 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Jan 2024 22:42:20 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <1uO8XMaqipFMM0s9VoxjdVheA4fidEaglMKSg8yjRYw=.ff42d280-8742-43ee-97cb-b4bb3ab6619d@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
 <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
 <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>
 <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>
 <1uO8XMaqipFMM0s9VoxjdVheA4fidEaglMKSg8yjRYw=.ff42d280-8742-43ee-97cb-b4bb3ab6619d@github.com>
Message-ID: <gvakwuF_W2-aoLbzy77M9AJo5d1wxSNT1v3tZnBj-yg=.3c42def2-471e-426d-bbe0-f7e59c1f730c@github.com>

On Wed, 3 Jan 2024 22:20:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)
>> 
>> Naively, I thought that something like this is possible _in principle_; I might be mistaken though:
>> 
>> diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java
>> index 851d65d06ad..014845860d0 100644
>> --- a/src/java.base/share/classes/java/lang/Class.java
>> +++ b/src/java.base/share/classes/java/lang/Class.java
>> @@ -4771,6 +4771,30 @@ public boolean isSealed() {
>>          return getPermittedSubclasses() != null;
>>      }
>>  
>> +    private boolean isNonSealed() {
>> +        if (isSealed())
>> +            return false;
>> +        if (!isInterface() && Modifier.isFinal(getModifiers())) {
>> +            // unlike interface, class can be final
>> +            return false;
>> +        }
>> +        // if an ancestor is sealed, this class can either be non-sealed or final
>> +        return hasSealedAncestor(this);
>> +    }
>> +
>> +    private boolean hasSealedAncestor(Class<?> clazz) {
>> +        var superclass = clazz.getSuperclass();
>> +        if (superclass != null) {
>> +            if (superclass.isSealed() || hasSealedAncestor(superclass))
>> +                return true;
>> +        }
>> +        for (var superinterface : clazz.getInterfaces()) {
>> +            if (superinterface.isSealed() || hasSealedAncestor(superinterface))
>> +                return true;
>> +        }
>> +        return false;
>> +    }
>> +
>>      private native Class<?>[] getPermittedSubclasses0();
>>  
>>      /*
>
> Thanks @pavelrappo; I'll explore incorporating functionality like this into the PR, probably next week.

> I think the best place, or least-bad place, to discuss the "modifier" ordering of sealed/non-sealed would be an informative note on Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are not represented in the class file as access flags and thus not modeled by this class [java.lang.reflect.Modifier] .... sealed/non-sealed should be presented in the same location as final."

Filed JDK-8322979: Add informative discussion to Modifier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1441050656

From jlu at openjdk.org  Wed Jan  3 23:38:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 Jan 2024 23:38:09 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun
Message-ID: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>

Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.

_LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.

In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).

Other updates
- For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
- For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
- Added comments for each test method

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

Commit messages:
 - remove LocaleProvidersLoggdersLogger from extending LocaleProvidersRun
 - replace non en locale check with Junit annotation
 - init

Changes: https://git.openjdk.org/jdk/pull/17257/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17257&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322235
  Stats: 554 lines in 7 files changed: 412 ins; 87 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/17257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17257/head:pull/17257

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

From zjx001202 at gmail.com  Thu Jan  4 03:36:28 2024
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 4 Jan 2024 11:36:28 +0800
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
Message-ID: <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>

Hey David,


> AFAICS java.library.path (and sun.boot.library.path) are input
> properties that can be set by the user. There are no "default" values
> for these properties as such.
>

Although they can be set by the user, they have default values.
For Linux, the default value is set here:


https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555

The default value on Linux is the LD_LIBRARY_PATH environment variable and
the paths I mentioned earlier.

The library loading will ultimately rely
> on the behaviour of dlopen, if no additional paths have been set, so it
> seems to me what you really want is for dlopen to act "the same way"
> that ld does. Note that dlopen will already check the contents of
> /etc/ld.so.cache
>

System.loadLibrary looks for the library in sun.boot.library.path and
java.library.path and passes the full path to the library to dlopen:

https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254

Therefore, the behavior of finding native libraries has nothing to do with
the behavior of dlopen, only sun.boot.library.path and java.library.path.

This does not seem practical. On my system ld.so.conf just contains
>
> include ld.so.conf.d/*.conf
>
> so now we (hotspot) have to read the top-level file, parse it, interpret
> it and then recursively read, parse and interpret more files.
>

Yes, this is exactly the behavior I want.

Glavo

On Tue, Jan 2, 2024 at 10:08?AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Glavo,
>
> On 24/12/2023 4:18 am, Glavo wrote:
> > 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.
>
> AFAICS java.library.path (and sun.boot.library.path) are input
> properties that can be set by the user. There are no "default" values
> for these properties as such. The library loading will ultimately rely
> on the behaviour of dlopen, if no additional paths have been set, so it
> seems to me what you really want is for dlopen to act "the same way"
> that ld does. Note that dlopen will already check the contents of
> /etc/ld.so.cache
>
> > 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?
>
> This does not seem practical. On my system ld.so.conf just contains
>
> include ld.so.conf.d/*.conf
>
> so now we (hotspot) have to read the top-level file, parse it, interpret
> it and then recursively read, parse and interpret more files.
>
> Cheers,
> David
> ----
>
>
> > Glavo
> >
> > [1]: https://wiki.ubuntu.com/MultiarchSpec
> > <https://wiki.ubuntu.com/MultiarchSpec>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240104/9870ac5f/attachment-0001.htm>

From joehw at openjdk.org  Thu Jan  4 05:07:27 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 4 Jan 2024 05:07:27 GMT
Subject: Integrated: 8322214: Return value of XMLInputFactory.getProperty()
 changed from boolean to String in JDK 22 early access builds
In-Reply-To: <YsSLbB-_MXD6vOpirDYiLPXI2RYS4vgFUy3KqKwoJpg=.a18fce9f-42ba-4fc3-8f74-896eb8438a1a@github.com>
References: <YsSLbB-_MXD6vOpirDYiLPXI2RYS4vgFUy3KqKwoJpg=.a18fce9f-42ba-4fc3-8f74-896eb8438a1a@github.com>
Message-ID: <ewr-AMN9RuJJQ5Uwd2-pEPu2_Vl8VuNvZbR2txwIj9Y=.871b944b-4200-47f0-88b2-14a029523cce@github.com>

On Wed, 3 Jan 2024 19:31:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix the get (return) operation by using the same method as that used for checking the values of the DTD features during the resolution process.
> 
> Note: this patch also addresses the issue reported in https://bugs.openjdk.org/browse/JDK-8322216
> 
> Test: new test added covers DTD properties for SAX/DOM/StAX.
>          Existing tests passed.

This pull request has now been integrated.

Changeset: 755722ce
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/755722ced60a686799c7f419feae61c04ce41f09
Stats:     144 lines in 3 files changed: 140 ins; 0 del; 4 mod

8322214: Return value of XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early access builds

Reviewed-by: lancea

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

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

From jbhateja at openjdk.org  Thu Jan  4 05:33:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 4 Jan 2024 05:33:35 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs for
 AVX2 target.
Message-ID: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>

Hi,

Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
These are very frequently used operation in columnar database filter operation.

Implementation uses a lookup table to record permute indices. Table index is computed using
mask argument of compress/expand operation.

Following are the performance number of JMH micro included with the patch.


System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)

Baseline:
Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms

Withopt:
Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   974.888          ops/ms
ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  1128.281          ops/ms
ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   686.334          ops/ms
ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   337.170          ops/ms


Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.

Changes: https://git.openjdk.org/jdk/pull/17261/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322768
  Stats: 336 lines in 10 files changed: 323 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17261/head:pull/17261

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

From jbhateja at openjdk.org  Thu Jan  4 05:39:01 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 4 Jan 2024 05:39:01 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used operation in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn      ...

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

  Updating copyright year of modified files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/3f2b6105..6bd9b0ad

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

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

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

From alanb at openjdk.org  Thu Jan  4 06:02:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Jan 2024 06:02:33 GMT
Subject: Integrated: 8322818: Thread::getStackTrace can fail with InternalError
 if virtual thread is timed-parked when pinned
In-Reply-To: <dRXi6Od3v6dYcDt1vTjQBzJ-CyJL_EU9d0YYhiIDMiE=.4552f5e0-b8bc-4e23-82be-19fbd70ee65f@github.com>
References: <dRXi6Od3v6dYcDt1vTjQBzJ-CyJL_EU9d0YYhiIDMiE=.4552f5e0-b8bc-4e23-82be-19fbd70ee65f@github.com>
Message-ID: <HDF88bVN9w1Qbz81SQx2SGarkfcPj6vakmPAXNYAfBs=.96b81bb4-077e-4ba7-a761-1f6b37499c58@github.com>

On Tue, 2 Jan 2024 08:55:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Missed by JDK-8312498, VirtualThread::tryGetStackTrace doesn't handle the TIMED_PINNED state so it's possible for Thread::getStackTrace to throw InternalError when invoked on a virtual thread that quickly transitions from unmounted to  timed-park-while-pinned. This one is needs a stress test to reproduce.

This pull request has now been integrated.

Changeset: 4db7a1c3
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4db7a1c3bb6b56cc7416aa27350406da27fe04a8
Stats:     78 lines in 2 files changed: 75 ins; 0 del; 3 mod

8322818: Thread::getStackTrace can fail with InternalError if virtual thread is timed-parked when pinned

Reviewed-by: pchilanomate

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

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

From david.holmes at oracle.com  Thu Jan  4 07:12:02 2024
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Jan 2024 17:12:02 +1000
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
 <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>
Message-ID: <4fa1375a-02e9-45da-a4f2-db7eba1c26e1@oracle.com>

On 4/01/2024 1:36 pm, Glavo wrote:
> Hey?David,
> 
>     AFAICS java.library.path (and sun.boot.library.path) are input
>     properties that can be set by the user. There are no "default" values
>     for these properties as such.
> 
> 
> Although they can be set by the user, they have default values.
> For Linux, the default value is set here:
> 
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555>
> 
> The default value on Linux is the LD_LIBRARY_PATH environment variable 
> and the paths I mentioned earlier.
> 
>     The library loading will ultimately rely
>     on the behaviour of dlopen, if no additional paths have been set, so it
>     seems to me what you really want is for dlopen to act "the same way"
>     that ld does. Note that dlopen will already check the contents of
>     /etc/ld.so.cache
> 
> 
> System.loadLibrary looks for the library in?sun.boot.library.path and 
> java.library.path?and passes the full path to the library to dlopen:
> 
>     https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254>
> 
> Therefore, the behavior of finding native libraries has nothing to do 
> with the behavior of dlopen, only sun.boot.library.path?and 
> java.library.path.

I stand corrected - apologies. I expected a raw name to simply get 
passed through. I thought both LD_LIBRARY_PATH and java.library.path 
could be used to expand the set of directories where the platform code 
looks for libs, not constrain things to only those paths (plus the 
defaults). I expect there are security reasons why the JDK tries to find 
the file itself in these specific paths, rather than letting the 
platform code search for it.

>     This does not seem practical. On my system ld.so.conf just contains
> 
>     include ld.so.conf.d/*.conf
> 
>     so now we (hotspot) have to read the top-level file, parse it, interpret
>     it and then recursively read, parse and interpret more files.
> 
> 
> Yes, this is exactly the behavior I want.

Well that is not something I would want to see implemented in hotspot.

Cheers,
David
-----

> Glavo
> 
> On Tue, Jan 2, 2024 at 10:08?AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Glavo,
> 
>     On 24/12/2023 4:18 am, Glavo wrote:
>      > 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.
> 
>     AFAICS java.library.path (and sun.boot.library.path) are input
>     properties that can be set by the user. There are no "default" values
>     for these properties as such. The library loading will ultimately rely
>     on the behaviour of dlopen, if no additional paths have been set, so it
>     seems to me what you really want is for dlopen to act "the same way"
>     that ld does. Note that dlopen will already check the contents of
>     /etc/ld.so.cache
> 
>      > 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?
> 
>     This does not seem practical. On my system ld.so.conf just contains
> 
>     include ld.so.conf.d/*.conf
> 
>     so now we (hotspot) have to read the top-level file, parse it,
>     interpret
>     it and then recursively read, parse and interpret more files.
> 
>     Cheers,
>     David
>     ----
> 
> 
>      > Glavo
>      >
>      > [1]: https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>
>      > <https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>>
> 

From mbaesken at openjdk.org  Thu Jan  4 08:09:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Jan 2024 08:09:34 GMT
Subject: Integrated: JDK-8322782: Clean up usages of unnecessary fully
 qualified class name "java.util.Arrays"
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <3omokFt2Z2o6tspIqc14e1qKWtD9FygYKsoXsHjHnI0=.f649ef22-6972-4008-8df0-f5e0dec1038a@github.com>

On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

This pull request has now been integrated.

Changeset: 1369c545
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1369c545ac51d7b5ff623d486e28c939869fecb8
Stats:     29 lines in 9 files changed: 0 ins; 0 del; 29 mod

8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays"

Reviewed-by: alanb, aivanov

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

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

From mbaesken at openjdk.org  Thu Jan  4 08:09:32 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Jan 2024 08:09:32 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <h5_ZKH7cVAf9LLYbYwTqfoD5L_UE2_KUlZZuDRQzckA=.3901c22a-ffc3-4a4b-9c93-059565a42682@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Hi Alexey, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1876673066

From shade at openjdk.org  Thu Jan  4 08:55:22 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 Jan 2024 08:55:22 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
Message-ID: <sNPdvXz8iIiSPTILKQ4MfLbfK2gCgjpIUrJ7JPzK4Ro=.66ebfd18-102a-48ce-b1fa-08fc545123a7@github.com>

On Wed, 3 Jan 2024 21:29:57 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> 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%.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup benchmark

I am good this this version. I would like a second Reviewer to ack this too.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17116#pullrequestreview-1803734314

From jlaskey at openjdk.org  Thu Jan  4 12:28:59 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 4 Jan 2024 12:28:59 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v3]
In-Reply-To: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
Message-ID: <H-OHEaed7CIrmKBUbnB9OMUQicklmhf5WTn29bEegVI=.28951b99-567d-4d2a-b811-caaf499044b4@github.com>

> The new repeat methods were not clearing the toStringCache.

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

 - Merge remote-tracking branch 'upstream/master' into 8322512
 - Clear sooner
 - Clear toStringCache when calling StringBuffer::repeat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17172/files
  - new: https://git.openjdk.org/jdk/pull/17172/files/66eb7f71..33dd7973

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

  Stats: 3615 lines in 286 files changed: 2156 ins; 564 del; 895 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 alanb at openjdk.org  Thu Jan  4 12:41:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Jan 2024 12:41:12 GMT
Subject: RFR: 8323002:
 test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
 times out on macosx-x64
Message-ID: <-4RpLtkDf3z2vXVsjvPf6ztqd_4X-4qYyThLrx9FmSY=.3c0726db-25fa-447c-8ae6-e52680fdff7a@github.com>

This test was recently added by JDK-8322818. On some test systems, the test passes a bit after the timeout so the test is marked as failed. The changes here dial down the iterations from 100k to 25k to reduce the execution time for release builds. No change for debug builds as this already uses a small number of iterations.

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

Commit messages:
 - Initial commit

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

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

From jlaskey at openjdk.org  Thu Jan  4 12:49:49 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 4 Jan 2024 12:49:49 GMT
Subject: Integrated: 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: <Sg0t83qxA_OKKefCabql24z1kX57XGyMsnTZ7GMYEGQ=.85fe64e7-11fc-44ea-adb5-016384ad8ce5@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.

This pull request has now been integrated.

Changeset: df22fb32
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df22fb322e6c4c9931a770bd0abf4c43b83c4e4a
Stats:     16 lines in 2 files changed: 15 ins; 0 del; 1 mod

8322512: StringBuffer.repeat does not work correctly after toString() was called

Reviewed-by: rriggs, jpai

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

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

From jlaskey at openjdk.org  Thu Jan  4 12:49:45 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 4 Jan 2024 12:49:45 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v4]
In-Reply-To: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
Message-ID: <ASHWuxqBNJ7n47CZG2yPcknpiKNpGwo7RBmBrdLFX2U=.55f2583c-6b54-432a-918c-d0c936837ac6@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:

  Nit in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17172/files
  - new: https://git.openjdk.org/jdk/pull/17172/files/33dd7973..ec72e77c

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 jlaskey at openjdk.org  Thu Jan  4 12:49:48 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 4 Jan 2024 12:49:48 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v2]
In-Reply-To: <yUVsv4S546vPlgikTle1iWBieDOoUVO-FAbsJCyoBEI=.cf27a6e7-2f29-4776-84c6-cf8cbce1ae7e@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
 <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
 <yUVsv4S546vPlgikTle1iWBieDOoUVO-FAbsJCyoBEI=.cf27a6e7-2f29-4776-84c6-cf8cbce1ae7e@github.com>
Message-ID: <W7sETezhrbaiK2qTXO7IzatQ4blrW24nfrBG7jAF1wM=.aa3a6de2-4bb6-4ec1-a18d-cbe543fde0d8@github.com>

On Thu, 21 Dec 2023 07:55:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clear sooner
>
> 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.

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17172#discussion_r1441707877

From alanb at openjdk.org  Thu Jan  4 12:53:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Jan 2024 12:53:07 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
 [v2]
In-Reply-To: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
Message-ID: <xhRyLulISbulbPO-wXe43fUzUZJ1X8-NG1K-bXLmIP4=.9fe1f89f-76f7-45b8-a82a-811fa47682d4@github.com>

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.

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

 - Expand TracePinnedThreads.testContention test description
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17221/files
  - new: https://git.openjdk.org/jdk/pull/17221/files/15993866..ab8a2bcb

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

  Stats: 2985 lines in 239 files changed: 1868 ins; 364 del; 753 mod
  Patch: https://git.openjdk.org/jdk/pull/17221.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17221/head:pull/17221

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

From jpai at openjdk.org  Thu Jan  4 13:25:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 Jan 2024 13:25:25 GMT
Subject: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang
 [v2]
In-Reply-To: <xhRyLulISbulbPO-wXe43fUzUZJ1X8-NG1K-bXLmIP4=.9fe1f89f-76f7-45b8-a82a-811fa47682d4@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
 <xhRyLulISbulbPO-wXe43fUzUZJ1X8-NG1K-bXLmIP4=.9fe1f89f-76f7-45b8-a82a-811fa47682d4@github.com>
Message-ID: <qGM5Lpl6cuOyEJXniVCudOYe9IjjqEmwLG38pBc0veM=.37c397f5-cd01-4ec4-9f28-d9efe67c8449@github.com>

On Thu, 4 Jan 2024 12:53:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
>> 
>> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Expand TracePinnedThreads.testContention test description
>  - Merge
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17221#pullrequestreview-1804149476

From duke at openjdk.org  Thu Jan  4 13:40:41 2024
From: duke at openjdk.org (Johny Jose)
Date: Thu, 4 Jan 2024 13:40:41 GMT
Subject: RFR: 8322725: (tz) Update Timezone Data to 2023d
Message-ID: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>

tzdata2023d changes

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

Commit messages:
 - 8322725: (tz) Update Timezone Data to 2023d

Changes: https://git.openjdk.org/jdk/pull/17268/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322725
  Stats: 140 lines in 14 files changed: 94 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/17268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17268/head:pull/17268

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

From epeter at openjdk.org  Thu Jan  4 13:45:26 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 4 Jan 2024 13:45:26 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
Message-ID: <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>

On Thu, 4 Jan 2024 05:39:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year of modified files.

@jatin-bhateja this looks like a great improvement!
I have a few questions and requests below.

FYI, this feels very inspiring. I'm dreaming of a day where we could do this filtering in the auto-vectorizer directly.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5303:

> 5301:     // Blend the results with zero vector using permute vector as mask, its
> 5302:     // non-participating lanes holds a -1 value.
> 5303:     vblendvps(dst, dst, xtmp, permv, vec_enc);

would you mind adding a few more comments to explain what happens here? I would also really appreciate more expressive register/variable names.

I think you are basically converting the `mask` to a permutation `permv`, by a lookup in the table.
Then you permute the `src` and blend it with a -1 vector, so that the unused (high) lanes are -1.


xtmp -> min_one
rtmp -> table_index
rscratch -> table_adr

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5307:

> 5305:     assert(bt == T_LONG || bt == T_DOUBLE, "");
> 5306:     vmovmskpd(rtmp, mask, vec_enc);
> 5307:     shlq(rtmp, 5);

Might this need to be 6? If I understand right, then you want to have a 64bit stride, hence 2^6, right?
If that is correct, then this did not show in your tests, and you need a regression test anyway.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp line 488:

> 486:                           KRegister ktmp1, int vec_enc);
> 487: 
> 488: 

Remove useless empty line

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 957:

> 955:   __ align(CodeEntryAlignment);
> 956:   StubCodeMark mark(this, "StubRoutines", stub_name);
> 957:   address start = __ pc();

Could you please add some comments here why you are filling the data like this?
Presumably, you are emitting 32 bits and 64 bits respectively, right? So the cells have different size, correct?

test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 76:

> 74:         longinCol = new long[size];
> 75:         longoutCol = new long[size];
> 76:         lpivot = size / 2;

I'd be interested to see what happens if you move up or down the "density" of elements that you accept. Would the simple branch prediction be faster if the density is low enough, i.e. we almost take no element.

Though maybe that is not compiler problem but a user-problem?

test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 94:

> 92:            IntVector vec = IntVector.fromArray(ispecies, intinCol, i);
> 93:            VectorMask<Integer> pred = vec.compare(VectorOperators.GT, ipivot);
> 94:            vec.compress(pred).intoArray(intoutCol, j);

Could there be equivalent `expand` tests?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1804121213
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441749005
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441761312
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441724949
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441759984
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441753158
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441729256

From epeter at openjdk.org  Thu Jan  4 13:45:27 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 4 Jan 2024 13:45:27 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
Message-ID: <tCv3NnHCTAIFIaUR08Vp7URLyP5DTnm3IREHk-Day2g=.2b7dce02-f2dc-4dee-adb5-ece24f0cd6ca@github.com>

On Thu, 4 Jan 2024 13:09:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 94:
> 
>> 92:            IntVector vec = IntVector.fromArray(ispecies, intinCol, i);
>> 93:            VectorMask<Integer> pred = vec.compare(VectorOperators.GT, ipivot);
>> 94:            vec.compress(pred).intoArray(intoutCol, j);
> 
> Could there be equivalent `expand` tests?

And what about some result verification? Or is there another test that does that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1441750595

From duke at openjdk.org  Thu Jan  4 13:46:21 2024
From: duke at openjdk.org (Johny Jose)
Date: Thu, 4 Jan 2024 13:46:21 GMT
Subject: RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <eYqYdEsFUcbqxVwWfS-mgLaLF_nj4u6bDK7cihKLSvM=.1b15408f-cfbe-4cbd-927a-d8397c58cd15@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

@naotoj Can you please review the changes

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

PR Comment: https://git.openjdk.org/jdk/pull/17268#issuecomment-1877117106

From duke at openjdk.org  Thu Jan  4 14:24:25 2024
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 4 Jan 2024 14:24:25 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v6]
In-Reply-To: <QfynfvBHCsW5azqDfHwnWYYQJVYLTpWIgXRgYo4LMEs=.34e1b6bc-7cc7-4098-930d-1c1564dd9ac4@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <FR8BSAikgxqhGe-_lkFNUI2TOQ4V-W1iNfptNe84CoE=.f501a415-2f10-4ae9-8ded-ffc02a02dd35@github.com>
 <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com>
 <QfynfvBHCsW5azqDfHwnWYYQJVYLTpWIgXRgYo4LMEs=.34e1b6bc-7cc7-4098-930d-1c1564dd9ac4@github.com>
Message-ID: <U2l-n79OYRnnTJZnK_YMPzyVGiVc1huduqdYumSn0vQ=.5f58ae10-db3d-4e7a-9e71-f53d1f193120@github.com>

On Wed, 3 Jan 2024 20:36:46 GMT, jmehrens <duke at openjdk.org> wrote:

> > I think this ticket should focus on adding the new constructor as part of the API.
> 
> Okay. I would think the code would avoid heapify when the caller does foolish things with this API such as:
> 
> ```
> SortedSet ss = filledSortedSet();
> PriorityQueue pq1 = new PriorityQueue(ss.comparator(), ss);
> 
> PriorityQueue pq = filledPriorityQueue();
> PriorityQueue pq2 = new PriorityQueue(pq.comparator(), pq);
> ```
> 
> I assume this constructor is going to be added to TreeSet, PriorityBlockingQueue, and ConcurrentSkipListSet?

why do you think the code would avoid heapify? `initFromCollection` method will be called regardless of the type of the collection passed, which will heapify the queue.

regarding adding the constructor to the other types mentioned, I believe I can be done, probably as part of a different ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1877175607

From zjx001202 at gmail.com  Thu Jan  4 14:24:01 2024
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 4 Jan 2024 22:24:01 +0800
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <4fa1375a-02e9-45da-a4f2-db7eba1c26e1@oracle.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
 <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>
 <4fa1375a-02e9-45da-a4f2-db7eba1c26e1@oracle.com>
Message-ID: <CAJL5A3k9TK=A8po+ms_Qx9gw8kVCB4=eh4r7+2Z1eF1tF+okcw@mail.gmail.com>

>
> I expect there are security reasons why the JDK tries to find
> the file itself in these specific paths, rather than letting the
> platform code search for it.
>

I think this should have nothing to do with security. If there is a
vulnerability in the platform code, there is nothing the JDK can do to
avoid it.

Well that is not something I would want to see implemented in hotspot.
>

This is the only way I can think of to get the JDK to behave consistently
with ld.
Maybe we should wait and see other developers who are more familiar with
this part.

I'm now sending this email to panama-dev as well.
I think this proposal is of great significance to Panama, as it will make
it easier for developers to develop wrappers for platform libraries.

Glavo

On Thu, Jan 4, 2024 at 3:12?PM David Holmes <david.holmes at oracle.com> wrote:

> On 4/01/2024 1:36 pm, Glavo wrote:
> > Hey David,
> >
> >     AFAICS java.library.path (and sun.boot.library.path) are input
> >     properties that can be set by the user. There are no "default" values
> >     for these properties as such.
> >
> >
> > Although they can be set by the user, they have default values.
> > For Linux, the default value is set here:
> >
> >
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555
> <
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555
> >
> >
> > The default value on Linux is the LD_LIBRARY_PATH environment variable
> > and the paths I mentioned earlier.
> >
> >     The library loading will ultimately rely
> >     on the behaviour of dlopen, if no additional paths have been set, so
> it
> >     seems to me what you really want is for dlopen to act "the same way"
> >     that ld does. Note that dlopen will already check the contents of
> >     /etc/ld.so.cache
> >
> >
> > System.loadLibrary looks for the library in sun.boot.library.path and
> > java.library.path and passes the full path to the library to dlopen:
> >
> >
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254
> <
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254
> >
> >
> > Therefore, the behavior of finding native libraries has nothing to do
> > with the behavior of dlopen, only sun.boot.library.path and
> > java.library.path.
>
> I stand corrected - apologies. I expected a raw name to simply get
> passed through. I thought both LD_LIBRARY_PATH and java.library.path
> could be used to expand the set of directories where the platform code
> looks for libs, not constrain things to only those paths (plus the
> defaults). I expect there are security reasons why the JDK tries to find
> the file itself in these specific paths, rather than letting the
> platform code search for it.
>
> >     This does not seem practical. On my system ld.so.conf just contains
> >
> >     include ld.so.conf.d/*.conf
> >
> >     so now we (hotspot) have to read the top-level file, parse it,
> interpret
> >     it and then recursively read, parse and interpret more files.
> >
> >
> > Yes, this is exactly the behavior I want.
>
> Well that is not something I would want to see implemented in hotspot.
>
> Cheers,
> David
> -----
>
> > Glavo
> >
> > On Tue, Jan 2, 2024 at 10:08?AM David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >
> >     Hi Glavo,
> >
> >     On 24/12/2023 4:18 am, Glavo wrote:
> >      > 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.
> >
> >     AFAICS java.library.path (and sun.boot.library.path) are input
> >     properties that can be set by the user. There are no "default" values
> >     for these properties as such. The library loading will ultimately
> rely
> >     on the behaviour of dlopen, if no additional paths have been set, so
> it
> >     seems to me what you really want is for dlopen to act "the same way"
> >     that ld does. Note that dlopen will already check the contents of
> >     /etc/ld.so.cache
> >
> >      > 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?
> >
> >     This does not seem practical. On my system ld.so.conf just contains
> >
> >     include ld.so.conf.d/*.conf
> >
> >     so now we (hotspot) have to read the top-level file, parse it,
> >     interpret
> >     it and then recursively read, parse and interpret more files.
> >
> >     Cheers,
> >     David
> >     ----
> >
> >
> >      > Glavo
> >      >
> >      > [1]: https://wiki.ubuntu.com/MultiarchSpec
> >     <https://wiki.ubuntu.com/MultiarchSpec>
> >      > <https://wiki.ubuntu.com/MultiarchSpec
> >     <https://wiki.ubuntu.com/MultiarchSpec>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240104/713b7ed6/attachment.htm>

From pchilanomate at openjdk.org  Thu Jan  4 14:56:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 4 Jan 2024 14:56:21 GMT
Subject: RFR: 8323002:
 test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
 times out on macosx-x64
In-Reply-To: <-4RpLtkDf3z2vXVsjvPf6ztqd_4X-4qYyThLrx9FmSY=.3c0726db-25fa-447c-8ae6-e52680fdff7a@github.com>
References: <-4RpLtkDf3z2vXVsjvPf6ztqd_4X-4qYyThLrx9FmSY=.3c0726db-25fa-447c-8ae6-e52680fdff7a@github.com>
Message-ID: <u5yYDqkRGVOKfyhLxi00EC55vY6h5rhHBXmgs_Jdb6A=.24893200-4c8c-4862-895d-6403495a197d@github.com>

On Thu, 4 Jan 2024 11:51:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test was recently added by JDK-8322818. On some test systems, the test passes a bit after the timeout so the test is marked as failed. The changes here dial down the iterations from 100k to 25k to reduce the execution time for release builds. No change for debug builds as this already uses a small number of iterations.

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17265#pullrequestreview-1804326778

From coffeys at openjdk.org  Thu Jan  4 15:13:21 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 4 Jan 2024 15:13:21 GMT
Subject: RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <imBWJNEeMQRsrpA3-FkpwYmYZ97nT-DDLSXBfDTphyw=.ea4286e5-f235-4731-b7bd-cf5555b2879e@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17268#pullrequestreview-1804359390

From alanb at openjdk.org  Thu Jan  4 15:23:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Jan 2024 15:23:32 GMT
Subject: RFR: 8323002:
 test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
 times out on macosx-x64
In-Reply-To: <u5yYDqkRGVOKfyhLxi00EC55vY6h5rhHBXmgs_Jdb6A=.24893200-4c8c-4862-895d-6403495a197d@github.com>
References: <-4RpLtkDf3z2vXVsjvPf6ztqd_4X-4qYyThLrx9FmSY=.3c0726db-25fa-447c-8ae6-e52680fdff7a@github.com>
 <u5yYDqkRGVOKfyhLxi00EC55vY6h5rhHBXmgs_Jdb6A=.24893200-4c8c-4862-895d-6403495a197d@github.com>
Message-ID: <f6m1bQfCghbIEWYXxAhQexu3cvZpdJYpwb8_AfNQjfc=.7826136b-ec85-428d-ba01-03b9775fc43c@github.com>

On Thu, 4 Jan 2024 14:53:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This test was recently added by JDK-8322818. On some test systems, the test passes a bit after the timeout so the test is marked as failed. The changes here dial down the iterations from 100k to 25k to reduce the execution time for release builds. No change for debug builds as this already uses a small number of iterations.
>
> Marked as reviewed by pchilanomate (Reviewer).

Thanks @pchilano.

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

PR Comment: https://git.openjdk.org/jdk/pull/17265#issuecomment-1877268522

From alanb at openjdk.org  Thu Jan  4 15:23:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Jan 2024 15:23:33 GMT
Subject: Integrated: 8323002:
 test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
 times out on macosx-x64
In-Reply-To: <-4RpLtkDf3z2vXVsjvPf6ztqd_4X-4qYyThLrx9FmSY=.3c0726db-25fa-447c-8ae6-e52680fdff7a@github.com>
References: <-4RpLtkDf3z2vXVsjvPf6ztqd_4X-4qYyThLrx9FmSY=.3c0726db-25fa-447c-8ae6-e52680fdff7a@github.com>
Message-ID: <jXZBchltsYQYSGC7BSdyKzyISLBHNymrgwAR7kNo0GQ=.d2779c78-2202-405c-ae39-e51b41812d0f@github.com>

On Thu, 4 Jan 2024 11:51:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test was recently added by JDK-8322818. On some test systems, the test passes a bit after the timeout so the test is marked as failed. The changes here dial down the iterations from 100k to 25k to reduce the execution time for release builds. No change for debug builds as this already uses a small number of iterations.

This pull request has now been integrated.

Changeset: d33dfe5c
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d33dfe5cb2bec682f94fbae850e167d6f437fecb
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8323002: test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java times out on macosx-x64

Reviewed-by: pchilanomate

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

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

From duke at openjdk.org  Thu Jan  4 15:36:24 2024
From: duke at openjdk.org (jmehrens)
Date: Thu, 4 Jan 2024 15:36:24 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v6]
In-Reply-To: <U2l-n79OYRnnTJZnK_YMPzyVGiVc1huduqdYumSn0vQ=.5f58ae10-db3d-4e7a-9e71-f53d1f193120@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <FR8BSAikgxqhGe-_lkFNUI2TOQ4V-W1iNfptNe84CoE=.f501a415-2f10-4ae9-8ded-ffc02a02dd35@github.com>
 <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com>
 <QfynfvBHCsW5azqDfHwnWYYQJVYLTpWIgXRgYo4LMEs=.34e1b6bc-7cc7-4098-930d-1c1564dd9ac4@github.com>
 <U2l-n79OYRnnTJZnK_YMPzyVGiVc1huduqdYumSn0vQ=.5f58ae10-db3d-4e7a-9e71-f53d1f193120@github.com>
Message-ID: <kpWEnnMLpJey3Z9XAD-Gi5w9_390N86bacbP5lPzlvw=.529a42fc-2b9e-4afd-9a9d-159def79b351@github.com>

On Thu, 4 Jan 2024 14:21:54 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

> why do you think the code would avoid heapify? `initFromCollection` method will be called regardless of the type of the collection passed, which will heapify the queue.

I simply mean to point out:

1.  That if the given comparator and the sortedset/priority queue comparator are the same then the call to heapify should be avoided as this is what is done in the [copy constructor.](https://github.com/openjdk/jdk/blob/139abc453f9eeeb4763076298ec44573ab94a3b6/src/java.base/share/classes/java/util/PriorityQueue.java#L196)
2. This new API has an anti-pattern not present with the other constructors.

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

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1877297438

From naoto at openjdk.org  Thu Jan  4 17:19:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:19:34 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: <xdxD6Zc7M-P2Gr8IDR027gYdZFqVH1KlG8Phl5q0jPE=.bcc5a0e2-057c-4f0f-8cfd-97f1bff1d2fa@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...

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17187#issuecomment-1877474644

From naoto at openjdk.org  Thu Jan  4 17:19:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:19:35 GMT
Subject: Integrated: 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: <7U1F8HZlHjkwQOMf9lgE6kQ0JF891LNcAynooll3Dbo=.2dc9121a-31a9-4681-977d-6101ddf283cf@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...

This pull request has now been integrated.

Changeset: ad31ec5c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad31ec5c5f120082cedd7b9ece45b6b44147c0c5
Stats:     94 lines in 3 files changed: 72 ins; 2 del; 20 mod

8322647: Short name for the `Europe/Lisbon` time zone is incorrect

Reviewed-by: joehw, iris

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

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

From jlu at openjdk.org  Thu Jan  4 17:19:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Jan 2024 17:19:35 GMT
Subject: Integrated: JDK-8319626: Override toString() for ZipFile
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: <k9CMZ2_YbI7wDEHHt5mAlq82GTKBKaSfzByFSix9H9o=.9a664b4c-4985-40d3-be02-00e6a0f6b599@github.com>

On Mon, 13 Nov 2023 21:59:05 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_).

This pull request has now been integrated.

Changeset: 15cf8f85
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15cf8f853105050ec356756d5affa153f79894fa
Stats:     14 lines in 1 file changed: 11 ins; 0 del; 3 mod

8319626: Override toString() for ZipFile

Reviewed-by: jpai, alanb, coffeys

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

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

From naoto at openjdk.org  Thu Jan  4 17:32:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:32:44 GMT
Subject: [jdk22] RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
Message-ID: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>

8322647: Short name for the `Europe/Lisbon` time zone is incorrect

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

Commit messages:
 - Backport ad31ec5c5f120082cedd7b9ece45b6b44147c0c5

Changes: https://git.openjdk.org/jdk22/pull/30/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=30&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/jdk22/pull/30.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/30/head:pull/30

PR: https://git.openjdk.org/jdk22/pull/30

From joehw at openjdk.org  Thu Jan  4 17:42:33 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 4 Jan 2024 17:42:33 GMT
Subject: [jdk22] RFR: 8322647: Short name for the `Europe/Lisbon` time zone
 is incorrect
In-Reply-To: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
References: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
Message-ID: <KWGA2wG7Tax9_Em3pG6hExibFT-PnJpveqipEp1LlYE=.ce66c9ed-38d1-44cd-823c-fb00802dfa68@github.com>

On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/30#pullrequestreview-1804685583

From naoto at openjdk.org  Thu Jan  4 17:54:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:54:23 GMT
Subject: RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <MyYwlRz7CHmhMO1j9PIpwDIPERM466h24cl9cy2UAdY=.bdf4c779-8c49-45cf-9c6a-2d7147d49322@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

LTGM too, assuming all the tests passed

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17268#pullrequestreview-1804702013

From naoto at openjdk.org  Thu Jan  4 17:54:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:54:24 GMT
Subject: [jdk22] Integrated: 8322647: Short name for the `Europe/Lisbon` time
 zone is incorrect
In-Reply-To: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
References: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
Message-ID: <WSeq-HZfVIKvNrhhcTCMRqHqL20vTq_090WC-HJwxfQ=.7d01ce32-b7ea-46fd-b23d-bb3d22afe2f6@github.com>

On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect

This pull request has now been integrated.

Changeset: a72afb38
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a72afb3845a7d245d462904e75b9368efefc0d39
Stats:     94 lines in 3 files changed: 72 ins; 2 del; 20 mod

8322647: Short name for the `Europe/Lisbon` time zone is incorrect

Reviewed-by: joehw
Backport-of: ad31ec5c5f120082cedd7b9ece45b6b44147c0c5

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

PR: https://git.openjdk.org/jdk22/pull/30

From duke at openjdk.org  Thu Jan  4 18:35:32 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 4 Jan 2024 18:35:32 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
Message-ID: <CXFT4o49n6-CFaPrzAhxY3bM4iKfkfQbFI6-C92YBCE=.ec79f802-d06d-4afe-8eb5-bb102a82af20@github.com>

On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.

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

> 648:                 } else {
> 649:                     // Prevent poisoning and leaking of buf
> 650:                     byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count);

@bplb Shouldn't it be `avail` *here*, too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17250#discussion_r1442120135

From mchung at openjdk.org  Thu Jan  4 18:37:23 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 4 Jan 2024 18:37:23 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v3]
In-Reply-To: <KL6Z0bEYXtPb0g7uD6wCp5C_tFQxskZXb2pzeSpY6kk=.94955a75-143d-40a3-831a-18b4d8702700@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
 <KL6Z0bEYXtPb0g7uD6wCp5C_tFQxskZXb2pzeSpY6kk=.94955a75-143d-40a3-831a-18b4d8702700@github.com>
Message-ID: <uh4maUBCGQffr1bfES1bWG6FmxpMphmHW3pt4P6U68w=.9046aa94-0837-425f-88f7-0cfb85721127@github.com>

On Wed, 3 Jan 2024 00:49:01 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:
> 
>   tests update per discussion with Ioi

Looks okay to me.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17178#pullrequestreview-1804764896

From duke at openjdk.org  Thu Jan  4 18:40:32 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 4 Jan 2024 18:40:32 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <YYrsku3dCzwKQrIupX_E8CGJ7A_YNsH32QaxCLsg4lE=.fe51b388-21bf-4e01-89e0-d04f9751414b@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
 <CXFT4o49n6-CFaPrzAhxY3bM4iKfkfQbFI6-C92YBCE=.ec79f802-d06d-4afe-8eb5-bb102a82af20@github.com>
 <YYrsku3dCzwKQrIupX_E8CGJ7A_YNsH32QaxCLsg4lE=.fe51b388-21bf-4e01-89e0-d04f9751414b@github.com>
Message-ID: <bhSmlb6PB0ov6nVvFxJ6lL1fC9iA5SS8J4NsNydl2_4=.46daa2cc-6554-443d-9d56-2452fa8892e2@github.com>

On Thu, 4 Jan 2024 18:35:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 650:
>> 
>>> 648:                 } else {
>>> 649:                     // Prevent poisoning and leaking of buf
>>> 650:                     byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count);
>> 
>> @bplb Shouldn't it be `avail` *here*, too?
>
> No: the third param of [Arrays.copyOfRange](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#copyOfRange(byte[],int,int)) is `to`, not `len`.

Ah, this explains why it did not fail originally, but only after adding the "isTrusted" case! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17250#discussion_r1442124151

From bpb at openjdk.org  Thu Jan  4 18:40:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 4 Jan 2024 18:40:31 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <CXFT4o49n6-CFaPrzAhxY3bM4iKfkfQbFI6-C92YBCE=.ec79f802-d06d-4afe-8eb5-bb102a82af20@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
 <CXFT4o49n6-CFaPrzAhxY3bM4iKfkfQbFI6-C92YBCE=.ec79f802-d06d-4afe-8eb5-bb102a82af20@github.com>
Message-ID: <YYrsku3dCzwKQrIupX_E8CGJ7A_YNsH32QaxCLsg4lE=.fe51b388-21bf-4e01-89e0-d04f9751414b@github.com>

On Thu, 4 Jan 2024 18:32:55 GMT, Markus KARG <duke at openjdk.org> wrote:

>> The final position instead of the number of bytes to write was being passed to `ByteArrayOuputStream.write(byte[],int,int)`.
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 650:
> 
>> 648:                 } else {
>> 649:                     // Prevent poisoning and leaking of buf
>> 650:                     byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count);
> 
> @bplb Shouldn't it be `avail` *here*, too?

No: the third param of [Arrays.copyOfRange](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#copyOfRange(byte[],int,int)) is `to`, not `len`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17250#discussion_r1442122428

From bpb at openjdk.org  Thu Jan  4 18:43:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 4 Jan 2024 18:43:33 GMT
Subject: RFR: 8322877: java/io/BufferedInputStream/TransferTo.java failed
 with IndexOutOfBoundsException
In-Reply-To: <bhSmlb6PB0ov6nVvFxJ6lL1fC9iA5SS8J4NsNydl2_4=.46daa2cc-6554-443d-9d56-2452fa8892e2@github.com>
References: <AqDddfxd8eS3FfdU5X4FCkf44NhLQqVrnM1mZnrbGtg=.699ada58-2b50-4c06-a3d2-94b4f4757421@github.com>
 <CXFT4o49n6-CFaPrzAhxY3bM4iKfkfQbFI6-C92YBCE=.ec79f802-d06d-4afe-8eb5-bb102a82af20@github.com>
 <YYrsku3dCzwKQrIupX_E8CGJ7A_YNsH32QaxCLsg4lE=.fe51b388-21bf-4e01-89e0-d04f9751414b@github.com>
 <bhSmlb6PB0ov6nVvFxJ6lL1fC9iA5SS8J4NsNydl2_4=.46daa2cc-6554-443d-9d56-2452fa8892e2@github.com>
Message-ID: <XDpUs2pl6Zk5QNFP6KEmrPBZ4nwAsGWgt_TR-ptflKU=.ac645385-4e3d-4d7b-9ec1-6bda57db265a@github.com>

On Thu, 4 Jan 2024 18:37:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> No: the third param of [Arrays.copyOfRange](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#copyOfRange(byte[],int,int)) is `to`, not `len`.
>
> Ah, this explains why it did not fail originally, but only after adding the "isTrusted" case! ?

See https://github.com/openjdk/jdk/pull/17250#issuecomment-1875761630 above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17250#discussion_r1442126261

From duke at openjdk.org  Thu Jan  4 19:00:43 2024
From: duke at openjdk.org (duke)
Date: Thu, 4 Jan 2024 19:00:43 GMT
Subject: Withdrawn: 8314544: Matrix multiply benchmark using Vector API
In-Reply-To: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
References: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
Message-ID: <YoERhBPNTtAOcqQ-ypZ6xjrZhibauz699oZRceDMK8M=.c65ed409-b670-4bb8-a25a-71f66ca99437@github.com>

On Fri, 18 Aug 2023 03:57:24 GMT, Martin Stypinski <duke at openjdk.org> wrote:

> Added a bunch of different implementations for Vector API Matrix Multiplications:
> 
> - Baseline
> - Blocked (Cache Local)
> - FMA
> - Vector API Simple Implementation
> - Vector API Blocked Implementation
> 
> Commit was discussed with @PaulSandoz

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Thu Jan  4 19:05:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:05:24 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <8KYg2XUArUxeAW7xH7-wP2ibaXYhzOiG65ytLUUsE6Y=.9e0aa2fa-09d7-41d7-bbac-dcb2d1267526@github.com>

On Wed, 3 Jan 2024 23:30:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
> - Added comments for each test method

Great to see this refactoring! Much cleaner now.

test/jdk/java/util/Locale/LocaleProvidersFormat.java line 30:

> 28:  * @library /test/lib
> 29:  * @build LocaleProviders
> 30:  *        providersrc.spi.src.tznp8013086

Although it is not needed in this test, I would list `tznp` to be built here, as the provider's meta-info includes both classes for completeness. Applies to `LocaleProvidersTimeZone` test too.

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

PR Review: https://git.openjdk.org/jdk/pull/17257#pullrequestreview-1804804618
PR Review Comment: https://git.openjdk.org/jdk/pull/17257#discussion_r1442145501

From joehw at openjdk.org  Thu Jan  4 19:15:44 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 4 Jan 2024 19:15:44 GMT
Subject: [jdk22] RFR: 8322214: Return value of XMLInputFactory.getProperty()
 changed from boolean to String in JDK 22 early access builds
Message-ID: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>

backport of PR: https://github.com/openjdk/jdk/pull/17252

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

Commit messages:
 - Backport 755722ced60a686799c7f419feae61c04ce41f09

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

PR: https://git.openjdk.org/jdk22/pull/32

From naoto at openjdk.org  Thu Jan  4 19:25:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:25:41 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v6]
In-Reply-To: <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com>
Message-ID: <JslKhkxUZqS5ooElquVSNQk5NaBAiFf6cGr3gsmBxdU=.def5cfe8-5bbf-46cd-a839-50a3647e2bec@github.com>

On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Restored the test
>  - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
>  - small cleanup
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Update ReferencedKeyTest.java
>  - Simple versions of create
>  - Add flag for reference queue type
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/99ea8bf2...b1f64e93

keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1877639764

From jlu at openjdk.org  Thu Jan  4 19:30:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Jan 2024 19:30:00 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v2]
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <emagDeQpr9-YfV62FoAa_hQL6gCUCK4UCeSYH_xzED4=.41465146-1251-405f-9f37-30a8b14d1957@github.com>

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
> - Added comments for each test method

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

 - cleanup comments
 - provide both SPI classes under build for relevant test files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17257/files
  - new: https://git.openjdk.org/jdk/pull/17257/files/b38b9909..a75237dc

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

  Stats: 23 lines in 5 files changed: 12 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/17257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17257/head:pull/17257

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

From jlu at openjdk.org  Thu Jan  4 19:30:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Jan 2024 19:30:00 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v2]
In-Reply-To: <8KYg2XUArUxeAW7xH7-wP2ibaXYhzOiG65ytLUUsE6Y=.9e0aa2fa-09d7-41d7-bbac-dcb2d1267526@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <8KYg2XUArUxeAW7xH7-wP2ibaXYhzOiG65ytLUUsE6Y=.9e0aa2fa-09d7-41d7-bbac-dcb2d1267526@github.com>
Message-ID: <THOfdHNK9gn-9-XbkMJBU2h0UAt8S0R5ilmkuAMYcak=.c0fa554e-bd86-4eb4-b5ef-bdefe6ca5d07@github.com>

On Thu, 4 Jan 2024 19:01:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - cleanup comments
>>  - provide both SPI classes under build for relevant test files
>
> test/jdk/java/util/Locale/LocaleProvidersFormat.java line 30:
> 
>> 28:  * @library /test/lib
>> 29:  * @build LocaleProviders
>> 30:  *        providersrc.spi.src.tznp8013086
> 
> Although it is not needed in this test, I would list `tznp` to be built here, as the provider's meta-info includes both classes for completeness. Applies to `LocaleProvidersTimeZone` test too.

That makes sense, updated both the relevant test files as you suggested. Thank you for taking the time to review this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17257#discussion_r1442166693

From naoto at openjdk.org  Thu Jan  4 19:31:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:31:26 GMT
Subject: [jdk22] RFR: 8322214: Return value of
 XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early
 access builds
In-Reply-To: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>
References: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>
Message-ID: <xyAjkdx4quh-qySNVnVxNjHlyLP7kHsJxwEOZm_zNcw=.fb42926b-d020-4e56-b7ff-3b4778efa0ea@github.com>

On Thu, 4 Jan 2024 19:09:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> backport of PR: https://github.com/openjdk/jdk/pull/17252

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/32#pullrequestreview-1804842674

From iris at openjdk.org  Thu Jan  4 19:37:26 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 4 Jan 2024 19:37:26 GMT
Subject: [jdk22] RFR: 8322214: Return value of
 XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early
 access builds
In-Reply-To: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>
References: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>
Message-ID: <TZKIJd2nnErtCVXdWun5C0Q4YARkhL08UAdl_aynozk=.6b3d4f8b-c6f7-4bab-9bf4-092269617bfe@github.com>

On Thu, 4 Jan 2024 19:09:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> backport of PR: https://github.com/openjdk/jdk/pull/17252

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/32#pullrequestreview-1804849821

From naoto at openjdk.org  Thu Jan  4 19:45:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:45:23 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v2]
In-Reply-To: <emagDeQpr9-YfV62FoAa_hQL6gCUCK4UCeSYH_xzED4=.41465146-1251-405f-9f37-30a8b14d1957@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <emagDeQpr9-YfV62FoAa_hQL6gCUCK4UCeSYH_xzED4=.41465146-1251-405f-9f37-30a8b14d1957@github.com>
Message-ID: <8AMY6YNVKUXnE5dqjYHWoAnKv5F9P7dTTmEKMeAZ2eg=.4aa44e24-a8df-4abb-af8f-a191f45ef1ac@github.com>

On Thu, 4 Jan 2024 19:30:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
>> 
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
>> 
>> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
>> 
>> Other updates
>> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
>> - For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
>> - Added comments for each test method
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup comments
>  - provide both SPI classes under build for relevant test files

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17257#pullrequestreview-1804861121

From ccheung at openjdk.org  Fri Jan  5 00:03:29 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 5 Jan 2024 00:03:29 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v2]
In-Reply-To: <X6As3w0bawd3coW-UchQXR4p13qb7Da3HzcOszD2s30=.d588a922-9d4a-49f6-a3f0-8482d9ec7804@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
 <2BOx3oXzgpyp3YbJGv3OsC76C4jv9MflhJPjJCCltys=.92e4bdc7-ab76-4896-8e85-3a7c78d94183@github.com>
 <X6As3w0bawd3coW-UchQXR4p13qb7Da3HzcOszD2s30=.d588a922-9d4a-49f6-a3f0-8482d9ec7804@github.com>
Message-ID: <TlN16ij6y9zlCslXN9LvuPHs5vwxa_ouqa6j2ql80RE=.a180b98c-f405-4e3a-b8fb-4658ed6028be@github.com>

On Sat, 23 Dec 2023 08:08:35 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
>
> Marked as reviewed by alanb (Reviewer).

Thanks @AlanBateman @mlchung for the reviews.
Also thanks @iklam for offline discussion and review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17178#issuecomment-1877923857

From ccheung at openjdk.org  Fri Jan  5 00:03:30 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 5 Jan 2024 00:03:30 GMT
Subject: Integrated: 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: <UWaUpBelxS4XZ1_OsBh4_6XwvwiTlYZV9O1_4SbxjFs=.bf11a36b-b660-476e-a423-cbbf1f7dc801@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.

This pull request has now been integrated.

Changeset: 3b1e56a4
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b1e56a4275addeadcefe180b5ce60d9d74cca7b
Stats:     64 lines in 4 files changed: 50 ins; 11 del; 3 mod

8322322: Support archived full module graph when -Xbootclasspath/a is used

Reviewed-by: alanb, mchung

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

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

From optusprepaid1 at gmail.com  Fri Jan  5 01:14:34 2024
From: optusprepaid1 at gmail.com (Bradley Willcott)
Date: Fri, 5 Jan 2024 09:14:34 +0800
Subject: New Java feature
Message-ID: <8e81c5da-6679-4765-a0e8-d196f95bad8d@gmail.com>

Hi there.
I am sorry if this is 'off subject'. However, where do I go to propose a 
new java feature? And please be nice :-).

Thanks,
Brad.

From davidalayachew at gmail.com  Fri Jan  5 01:41:06 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 4 Jan 2024 20:41:06 -0500
Subject: New Java feature
In-Reply-To: <CAA9v-_MED0XWpKD53uVw7sDyWSNgLaOXJJc5egJbARVkNuUoNw@mail.gmail.com>
References: <8e81c5da-6679-4765-a0e8-d196f95bad8d@gmail.com>
 <CAA9v-_MED0XWpKD53uVw7sDyWSNgLaOXJJc5egJbARVkNuUoNw@mail.gmail.com>
Message-ID: <CAA9v-_NS2qTZkkoV3uuw-DED8-MfWKtVy_J-Tit1k2FCnSKgLg@mail.gmail.com>

Try and search up the idea before posting though. A lot of people have made
feature requests before you.

On Thu, Jan 4, 2024 at 8:40?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> amber-dev at openjdk.org
>
> On Thu, Jan 4, 2024 at 8:29?PM Bradley Willcott <optusprepaid1 at gmail.com>
> wrote:
>
>> Hi there.
>> I am sorry if this is 'off subject'. However, where do I go to propose a
>> new java feature? And please be nice :-).
>>
>> Thanks,
>> Brad.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240104/c0a3f175/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Jan  5 01:40:24 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 4 Jan 2024 20:40:24 -0500
Subject: New Java feature
In-Reply-To: <8e81c5da-6679-4765-a0e8-d196f95bad8d@gmail.com>
References: <8e81c5da-6679-4765-a0e8-d196f95bad8d@gmail.com>
Message-ID: <CAA9v-_MED0XWpKD53uVw7sDyWSNgLaOXJJc5egJbARVkNuUoNw@mail.gmail.com>

amber-dev at openjdk.org

On Thu, Jan 4, 2024 at 8:29?PM Bradley Willcott <optusprepaid1 at gmail.com>
wrote:

> Hi there.
> I am sorry if this is 'off subject'. However, where do I go to propose a
> new java feature? And please be nice :-).
>
> Thanks,
> Brad.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240104/44e139f1/attachment.htm>

From joehw at openjdk.org  Fri Jan  5 02:29:31 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 5 Jan 2024 02:29:31 GMT
Subject: [jdk22] Integrated: 8322214: Return value of
 XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early
 access builds
In-Reply-To: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>
References: <jOoP89ovCbLvt9DaXpAOYwP9bBj2NMRE3Aan0jg3EAk=.dd65476f-f8e8-41ac-88f6-7295d1d45b7a@github.com>
Message-ID: <2XgM-ZxEzrp7t7gpd1l769ZnOfkPC0zr15t7iPZboTo=.5a9c0256-427a-40a4-ad98-afe0192bd7f5@github.com>

On Thu, 4 Jan 2024 19:09:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> backport of PR: https://github.com/openjdk/jdk/pull/17252

This pull request has now been integrated.

Changeset: b1219319
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b121931959e08951a8cc02eb925a77657441f175
Stats:     144 lines in 3 files changed: 140 ins; 0 del; 4 mod

8322214: Return value of XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early access builds

Reviewed-by: naoto, iris
Backport-of: 755722ced60a686799c7f419feae61c04ce41f09

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

PR: https://git.openjdk.org/jdk22/pull/32

From david.holmes at oracle.com  Fri Jan  5 05:56:17 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 Jan 2024 15:56:17 +1000
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <CAJL5A3k9TK=A8po+ms_Qx9gw8kVCB4=eh4r7+2Z1eF1tF+okcw@mail.gmail.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
 <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>
 <4fa1375a-02e9-45da-a4f2-db7eba1c26e1@oracle.com>
 <CAJL5A3k9TK=A8po+ms_Qx9gw8kVCB4=eh4r7+2Z1eF1tF+okcw@mail.gmail.com>
Message-ID: <5cf81082-4173-4132-9614-86640bb366f1@oracle.com>

On 5/01/2024 12:24 am, Glavo wrote:
>     I expect there are security reasons why the JDK tries to find
>     the file itself in these specific paths, rather than letting the
>     platform code search for it.
> 
> 
> I think this should have nothing to do with security.?If there is a 
> vulnerability in the platform code, there is nothing the JDK can do to 
> avoid it.

I did some archaeology and this has basically worked this way since it 
was introduced way back in 1998. As far as I can see there was never any 
discussion/suggestion that if we fail to find a library by the 
classloader mechanisms (using java.library.path etc.) that we just pass 
it through to the platform loader (e.g. dlopen) to try and find it. This 
may be an oversight, or it may relate to how the classloader has to 
maintain a mapping between library names and actual library files (which 
would be difficult if dlopen does the searching implicitly).

>     Well that is not something I would want to see implemented in hotspot.
> 
> 
> This is the only way I can think of to get the JDK to behave 
> consistently with ld.
> Maybe we should wait and see other developers who are more familiar with 
> this part.

Certainly. But IMHO neither core-libs folk, not hotspot folk, will want 
to be in the business of having to load, parse and interpret 
/etc/ld.so.conf and its related files.

> I'm now sending this email to panama-dev as well.
> I think this proposal is of great significance to Panama, as it will 
> make it easier for developers to develop wrappers for platform libraries.

It will be interesting to see what they say.

Cheers,
David
-----

> Glavo
> 
> On Thu, Jan 4, 2024 at 3:12?PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 4/01/2024 1:36 pm, Glavo wrote:
>      > Hey?David,
>      >
>      >? ? ?AFAICS java.library.path (and sun.boot.library.path) are input
>      >? ? ?properties that can be set by the user. There are no
>     "default" values
>      >? ? ?for these properties as such.
>      >
>      >
>      > Although they can be set by the user, they have default values.
>      > For Linux, the default value is set here:
>      >
>      >
>     https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555> <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555>>
>      >
>      > The default value on Linux is the LD_LIBRARY_PATH environment
>     variable
>      > and the paths I mentioned earlier.
>      >
>      >? ? ?The library loading will ultimately rely
>      >? ? ?on the behaviour of dlopen, if no additional paths have been
>     set, so it
>      >? ? ?seems to me what you really want is for dlopen to act "the
>     same way"
>      >? ? ?that ld does. Note that dlopen will already check the contents of
>      >? ? ?/etc/ld.so.cache
>      >
>      >
>      > System.loadLibrary looks for the library in?sun.boot.library.path
>     and
>      > java.library.path?and passes the full path to the library to dlopen:
>      >
>      >
>     https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254> <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254>>
>      >
>      > Therefore, the behavior of finding native libraries has nothing
>     to do
>      > with the behavior of dlopen, only sun.boot.library.path?and
>      > java.library.path.
> 
>     I stand corrected - apologies. I expected a raw name to simply get
>     passed through. I thought both LD_LIBRARY_PATH and java.library.path
>     could be used to expand the set of directories where the platform code
>     looks for libs, not constrain things to only those paths (plus the
>     defaults). I expect there are security reasons why the JDK tries to
>     find
>     the file itself in these specific paths, rather than letting the
>     platform code search for it.
> 
>      >? ? ?This does not seem practical. On my system ld.so.conf just
>     contains
>      >
>      >? ? ?include ld.so.conf.d/*.conf
>      >
>      >? ? ?so now we (hotspot) have to read the top-level file, parse
>     it, interpret
>      >? ? ?it and then recursively read, parse and interpret more files.
>      >
>      >
>      > Yes, this is exactly the behavior I want.
> 
>     Well that is not something I would want to see implemented in hotspot.
> 
>     Cheers,
>     David
>     -----
> 
>      > Glavo
>      >
>      > On Tue, Jan 2, 2024 at 10:08?AM David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>      > <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>> wrote:
>      >
>      >? ? ?Hi Glavo,
>      >
>      >? ? ?On 24/12/2023 4:18 am, Glavo wrote:
>      >? ? ? > 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.
>      >
>      >? ? ?AFAICS java.library.path (and sun.boot.library.path) are input
>      >? ? ?properties that can be set by the user. There are no
>     "default" values
>      >? ? ?for these properties as such. The library loading will
>     ultimately rely
>      >? ? ?on the behaviour of dlopen, if no additional paths have been
>     set, so it
>      >? ? ?seems to me what you really want is for dlopen to act "the
>     same way"
>      >? ? ?that ld does. Note that dlopen will already check the contents of
>      >? ? ?/etc/ld.so.cache
>      >
>      >? ? ? > 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?
>      >
>      >? ? ?This does not seem practical. On my system ld.so.conf just
>     contains
>      >
>      >? ? ?include ld.so.conf.d/*.conf
>      >
>      >? ? ?so now we (hotspot) have to read the top-level file, parse it,
>      >? ? ?interpret
>      >? ? ?it and then recursively read, parse and interpret more files.
>      >
>      >? ? ?Cheers,
>      >? ? ?David
>      >? ? ?----
>      >
>      >
>      >? ? ? > Glavo
>      >? ? ? >
>      >? ? ? > [1]: https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>
>      >? ? ?<https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>>
>      >? ? ? > <https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>
>      >? ? ?<https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>>>
>      >
> 

From lmesnik at openjdk.org  Fri Jan  5 07:00:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Jan 2024 07:00:20 GMT
Subject: RFR: 8322920: Some ProcessTools.execute* functions are declared to
 throw Throwable
In-Reply-To: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
References: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
Message-ID: <4rCL43GABcMC2SMvhVGi_31M9mUeA6QODULxeAKSE-k=.3ef2cfab-1d34-4821-a27b-46a34e50d5cc@github.com>

On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Most functions in ProcessTools are declared to throw Exceptions, or one of its subclasses. However, there are a small number of functions that are unnecessarily declared to throw Throwable instead of Exception. I propose that we change them to also be declared to throw Exception.
> 
> This is a trivial patch to make it easier to refactor tests to use the updated functions.
> 
> Tested manually, but will wait for GHA to verify that the change is OK.

You need to update copyrights.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17240#pullrequestreview-1805436752

From jbhateja at openjdk.org  Fri Jan  5 07:08:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 5 Jan 2024 07:08:35 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v3]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <tfYUCVwnSbUfHmrDgmCCefDbWdPgU7kTzSTr5J2T864=.9d5cdeff-3212-4b38-b3db-b921978a3dc1@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

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

  Review comments resolutions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/6bd9b0ad..ea0aa0b4

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

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

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

From jbhateja at openjdk.org  Fri Jan  5 07:08:37 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 5 Jan 2024 07:08:37 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
Message-ID: <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>

On Thu, 4 Jan 2024 13:41:40 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5307:
> 
>> 5305:     assert(bt == T_LONG || bt == T_DOUBLE, "");
>> 5306:     vmovmskpd(rtmp, mask, vec_enc);
>> 5307:     shlq(rtmp, 5);
> 
> Might this need to be 6? If I understand right, then you want to have a 64bit stride, hence 2^6, right?
> If that is correct, then this did not show in your tests, and you need a regression test anyway.

This computes the byte offset from start of the table, both integer and long permute table have same row sizes, 8 int elements vs 4 long elements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442555037

From jbhateja at openjdk.org  Fri Jan  5 07:08:39 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 5 Jan 2024 07:08:39 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <tCv3NnHCTAIFIaUR08Vp7URLyP5DTnm3IREHk-Day2g=.2b7dce02-f2dc-4dee-adb5-ece24f0cd6ca@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <tCv3NnHCTAIFIaUR08Vp7URLyP5DTnm3IREHk-Day2g=.2b7dce02-f2dc-4dee-adb5-ece24f0cd6ca@github.com>
Message-ID: <2ykpNJfFJYotuyI59zfh966TIQYUF2Id6NR56zpq_Vw=.6b3b5411-e086-45df-8666-2496ac013548@github.com>

On Thu, 4 Jan 2024 13:30:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 94:
>> 
>>> 92:            IntVector vec = IntVector.fromArray(ispecies, intinCol, i);
>>> 93:            VectorMask<Integer> pred = vec.compare(VectorOperators.GT, ipivot);
>>> 94:            vec.compress(pred).intoArray(intoutCol, j);
>> 
>> Could there be equivalent `expand` tests?
>
> And what about some result verification? Or is there another test that does that?

We do have extensive functional tests for compress/expand APIs in [test/jdk/jdk/incubator/vector](https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/incubator/vector)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442554968

From jbhateja at openjdk.org  Fri Jan  5 07:08:40 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 5 Jan 2024 07:08:40 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <2ykpNJfFJYotuyI59zfh966TIQYUF2Id6NR56zpq_Vw=.6b3b5411-e086-45df-8666-2496ac013548@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <tCv3NnHCTAIFIaUR08Vp7URLyP5DTnm3IREHk-Day2g=.2b7dce02-f2dc-4dee-adb5-ece24f0cd6ca@github.com>
 <2ykpNJfFJYotuyI59zfh966TIQYUF2Id6NR56zpq_Vw=.6b3b5411-e086-45df-8666-2496ac013548@github.com>
Message-ID: <RO4L3O7d9wghJPWZ5p_GokrNC_uz_TosOqlMI6_b56U=.340658c9-fad8-41bf-8837-244d7d9dd9d1@github.com>

On Fri, 5 Jan 2024 07:03:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> And what about some result verification? Or is there another test that does that?
>
> We do have extensive functional tests for compress/expand APIs in [test/jdk/jdk/incubator/vector](https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/incubator/vector)

> Could there be equivalent `expand` tests?

Here are the performance number for existing [VectorAPI JMH micros.](https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation)

![image](https://github.com/openjdk/jdk/assets/59989778/4b260814-3d3c-4e9b-b81a-61492ea48cce)
![image](https://github.com/openjdk/jdk/assets/59989778/50048281-ad50-44f6-a875-308e02537be2)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442556253

From jbhateja at openjdk.org  Fri Jan  5 07:11:23 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 5 Jan 2024 07:11:23 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
Message-ID: <_guczAND7qope6gMYcZVaolzJE0FnlRfhm9RsgFS5eY=.15982e8f-229f-4d8d-a184-06a62288775a@github.com>

On Thu, 4 Jan 2024 13:33:08 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 76:
> 
>> 74:         longinCol = new long[size];
>> 75:         longoutCol = new long[size];
>> 76:         lpivot = size / 2;
> 
> I'd be interested to see what happens if you move up or down the "density" of elements that you accept. Would the simple branch prediction be faster if the density is low enough, i.e. we almost take no element.
> 
> Though maybe that is not compiler problem but a user-problem?

Included fuzzy filter micro with varying mask density.
![image](https://github.com/openjdk/jdk/assets/59989778/a6af21cc-36c0-4503-aeb3-e66b862da2e1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442557565

From duke at openjdk.org  Fri Jan  5 08:15:33 2024
From: duke at openjdk.org (Johny Jose)
Date: Fri, 5 Jan 2024 08:15:33 GMT
Subject: Integrated: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <4UBo8oLvyPwMubDYKzSz1PqINlWsRhxbejzSL4wN9AY=.e6479968-1879-4678-9679-5f201ed3be81@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

This pull request has now been integrated.

Changeset: 2a9c3589
Author:    Johny Jose <johny.jose at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc
Stats:     140 lines in 14 files changed: 94 ins; 15 del; 31 mod

8322725: (tz) Update Timezone Data to 2023d

Reviewed-by: coffeys, naoto

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

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

From pminborg at openjdk.org  Fri Jan  5 08:22:14 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 5 Jan 2024 08:22:14 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v8]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <yXPlqcWMC6de4xbuHl25k_yXY4O7u6Jl5zIkvOi6NF0=.0ca222d4-016a-483b-8094-3786bc9d7b31@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:

  Fix formatting in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/115b6ea6..67091945

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

  Stats: 3 lines in 1 file 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 stefank at openjdk.org  Fri Jan  5 08:22:41 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Jan 2024 08:22:41 GMT
Subject: RFR: 8322920: Some ProcessTools.execute* functions are declared to
 throw Throwable [v2]
In-Reply-To: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
References: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
Message-ID: <-LmjrWlv9MLQKE-D_pYAvoON1RcsV_nXZV0FSV9eU6I=.4c035aa5-eb06-45ba-94d4-c23a37e949f4@github.com>

> Most functions in ProcessTools are declared to throw Exceptions, or one of its subclasses. However, there are a small number of functions that are unnecessarily declared to throw Throwable instead of Exception. I propose that we change them to also be declared to throw Exception.
> 
> This is a trivial patch to make it easier to refactor tests to use the updated functions.
> 
> Tested manually, but will wait for GHA to verify that the change is OK.

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

  Copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17240/files
  - new: https://git.openjdk.org/jdk/pull/17240/files/910a863c..402b6727

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

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

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

From pminborg at openjdk.org  Fri Jan  5 08:25:56 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 5 Jan 2024 08:25:56 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v9]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <DOdpbCs3KYi6dObUedFRU8kH9mjZG4jDoNBI0RsIOgk=.e949f98d-74d6-4bfe-8890-bc50658ac058@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:

  Fix docs for read-only exceptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/67091945..4d7c58ad

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

  Stats: 4 lines in 1 file changed: 0 ins; 3 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 pminborg at openjdk.org  Fri Jan  5 08:36:56 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 5 Jan 2024 08:36:56 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v10]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <RhZkUsV6RIrJ0_oGXVRX8r9u3mZLqS8WOp7mcwMu51U=.6dafbbed-67c0-44ba-8d4e-31c2300002cd@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 with a new target base 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 throw-change2
 - Fix docs for read-only exceptions
 - Fix formatting in test
 - Move @throws tag
 - Correct exception type in JavaDocs for SA:allocateFrom
 - Update after comments
 - Revert change in allocateNoInit
 - Remove Math.multiply exact and change exception type
 - Update after comments and discussion
 - Change the exception thrown for certain negative long values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/4d7c58ad..7d5472c5

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

  Stats: 8635 lines in 594 files changed: 5231 ins; 1384 del; 2020 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 stefank at openjdk.org  Fri Jan  5 09:07:57 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Jan 2024 09:07:57 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v3]
In-Reply-To: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
Message-ID: <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'upstream/master' into 8320699_OutputAnalyzer_progress_logging
 - Update OutputBuffer.java copyright years
 - 8320699: Add parameter to skip progress logging of OutputAnalyzer

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

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

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

From stefank at openjdk.org  Fri Jan  5 09:10:36 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Jan 2024 09:10:36 GMT
Subject: Integrated: 8322920: Some ProcessTools.execute* functions are declared
 to throw Throwable
In-Reply-To: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
References: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
Message-ID: <vLll_091EPQbs5wiqunT25Kc5x6gOSik4FxPIwF_G6s=.56477e9e-1d2e-422d-a76a-eae4a9b31cf2@github.com>

On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Most functions in ProcessTools are declared to throw Exceptions, or one of its subclasses. However, there are a small number of functions that are unnecessarily declared to throw Throwable instead of Exception. I propose that we change them to also be declared to throw Exception.
> 
> This is a trivial patch to make it easier to refactor tests to use the updated functions.
> 
> Tested manually, but will wait for GHA to verify that the change is OK.

This pull request has now been integrated.

Changeset: 868f8745
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/868f8745faf70c915d8294ae8f85b2d6aa096900
Stats:     6 lines in 1 file changed: 0 ins; 2 del; 4 mod

8322920: Some ProcessTools.execute* functions are declared to throw Throwable

Reviewed-by: dholmes, lmesnik

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

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

From stefank at openjdk.org  Fri Jan  5 09:10:34 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Jan 2024 09:10:34 GMT
Subject: RFR: 8322920: Some ProcessTools.execute* functions are declared to
 throw Throwable [v2]
In-Reply-To: <-LmjrWlv9MLQKE-D_pYAvoON1RcsV_nXZV0FSV9eU6I=.4c035aa5-eb06-45ba-94d4-c23a37e949f4@github.com>
References: <Yf9vedRICVKteiAD-m3jMSf-JcOATCItUvk4e_-23jc=.8cf4db77-178c-4c39-b0b8-5a1bb44836d4@github.com>
 <-LmjrWlv9MLQKE-D_pYAvoON1RcsV_nXZV0FSV9eU6I=.4c035aa5-eb06-45ba-94d4-c23a37e949f4@github.com>
Message-ID: <2feO9th9WhvBCIf18liAUgASvP_3i51NHk0dcHsxpdI=.60a3c59d-cec0-43f4-bca5-68c80191596f@github.com>

On Fri, 5 Jan 2024 08:22:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Most functions in ProcessTools are declared to throw Exceptions, or one of its subclasses. However, there are a small number of functions that are unnecessarily declared to throw Throwable instead of Exception. I propose that we change them to also be declared to throw Exception.
>> 
>> This is a trivial patch to make it easier to refactor tests to use the updated functions.
>> 
>> Tested manually, but will wait for GHA to verify that the change is OK.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year

Thanks for the reviews. Testing with Tier1-3 passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/17240#issuecomment-1878341513

From epeter at openjdk.org  Fri Jan  5 10:05:22 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Jan 2024 10:05:22 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v3]
In-Reply-To: <tfYUCVwnSbUfHmrDgmCCefDbWdPgU7kTzSTr5J2T864=.9d5cdeff-3212-4b38-b3db-b921978a3dc1@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <tfYUCVwnSbUfHmrDgmCCefDbWdPgU7kTzSTr5J2T864=.9d5cdeff-3212-4b38-b3db-b921978a3dc1@github.com>
Message-ID: <YtwzrosQJ7O7vNqkuSgzNJWnJMP3jjDY8cNvpPwdeiI=.4b1b7818-39da-4afb-944c-1a2fc8db21f7@github.com>

On Fri, 5 Jan 2024 07:08:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Thanks for the updates!

One more idea: Your AVX2 solution has a lot of cost for converting the mask to a permutation. Might it make sense to split this off into a separate vector-node, so that it can float out of a loop if the mask is invariant?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 963:

> 961:     // or a -1 (default) value.
> 962:     for (int i = 0; i < 256; i++) {
> 963:       int tmp = i;

why is `tmp` needed? Would it not be better to replace `i` with `mask` (i.e. the bit pattern that is then translated to a permutation)?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 966:

> 964:       int ctr = 0;
> 965:       for (int j = 0; j < 8; j++) {
> 966:         if (tmp & (1 << j)) {

Suggestion:

        if (mask & (1 << j)) {

would be much more readable

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1805616736
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442664755
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442668939

From epeter at openjdk.org  Fri Jan  5 10:05:23 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Jan 2024 10:05:23 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
Message-ID: <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>

On Fri, 5 Jan 2024 07:03:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5307:
>> 
>>> 5305:     assert(bt == T_LONG || bt == T_DOUBLE, "");
>>> 5306:     vmovmskpd(rtmp, mask, vec_enc);
>>> 5307:     shlq(rtmp, 5);
>> 
>> Might this need to be 6? If I understand right, then you want to have a 64bit stride, hence 2^6, right?
>> If that is correct, then this did not show in your tests, and you need a regression test anyway.
>
> This computes the byte offset from start of the table, both integer and long permute table have same row sizes, 8 int elements vs 4 long elements.

Ah, I understand now. Maybe leave a comment for that?

>> test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 76:
>> 
>>> 74:         longinCol = new long[size];
>>> 75:         longoutCol = new long[size];
>>> 76:         lpivot = size / 2;
>> 
>> I'd be interested to see what happens if you move up or down the "density" of elements that you accept. Would the simple branch prediction be faster if the density is low enough, i.e. we almost take no element.
>> 
>> Though maybe that is not compiler problem but a user-problem?
>
> Included fuzzy filter micro with varying mask density.
> ![image](https://github.com/openjdk/jdk/assets/59989778/a6af21cc-36c0-4503-aeb3-e66b862da2e1)

You are using `VectorMask<Integer> pred = VectorMask.fromLong(ispecies, maskctr++);`.
That basically systematically iterates over all masks, which is nice for a correctness test.
But that would use different density inside one test run, right? The average over the loop is still at `50%`, correct?

I was thinking more a run where the percentage over the whole loop is lower than maybe `1%`. That would get us to a point where maybe the branch prediction of non-vectorized code might be faster, what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442670411
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442676633

From epeter at openjdk.org  Fri Jan  5 10:05:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Jan 2024 10:05:24 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
 <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
Message-ID: <Ij8qwXTtnULBMFLg1HyKAi0ObNVug_nxLleb1_jAhjQ=.269b71ed-3a3f-41db-8d79-6d1821820e57@github.com>

On Fri, 5 Jan 2024 09:37:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This computes the byte offset from start of the table, both integer and long permute table have same row sizes, 8 int elements vs 4 long elements.
>
> Ah, I understand now. Maybe leave a comment for that?

I would say something like this:
Given a `mask`, we compute the index into the permutation table, and load the corresponding `permutation` (4 long elements).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442688495

From epeter at openjdk.org  Fri Jan  5 10:05:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Jan 2024 10:05:28 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <qGw_jW6FX1xT8LDjyq_wurofawY23c5yPMuTn_jFlps=.b31ecc8f-3fef-4018-8f66-a1408a60a4ac@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <qGw_jW6FX1xT8LDjyq_wurofawY23c5yPMuTn_jFlps=.b31ecc8f-3fef-4018-8f66-a1408a60a4ac@github.com>
Message-ID: <YKyGqXZGEtLDYYiOf2m4C-Bj10hPlKu3iQBEG_U6D54=.e7ed83dd-0ef4-4e77-9c65-dd0426e2cd53@github.com>

On Fri, 5 Jan 2024 09:31:50 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 957:
>> 
>>> 955:   __ align(CodeEntryAlignment);
>>> 956:   StubCodeMark mark(this, "StubRoutines", stub_name);
>>> 957:   address start = __ pc();
>> 
>> Could you please add some comments here why you are filling the data like this?
>> Presumably, you are emitting 32 bits and 64 bits respectively, right? So the cells have different size, correct?
>
> Thanks for the comment addition!

Improvement suggestion:
For a vector with 8 ints, we get `2^8 = 256` many bit patterns for the mask. The table has a row for each `mask` value, consisting of 8 ints, which provide the valid permute index corresponding to set bit position in the `mask`, or a -1 (default) value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442668440

From epeter at openjdk.org  Fri Jan  5 10:05:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Jan 2024 10:05:28 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <RO4L3O7d9wghJPWZ5p_GokrNC_uz_TosOqlMI6_b56U=.340658c9-fad8-41bf-8837-244d7d9dd9d1@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <tCv3NnHCTAIFIaUR08Vp7URLyP5DTnm3IREHk-Day2g=.2b7dce02-f2dc-4dee-adb5-ece24f0cd6ca@github.com>
 <2ykpNJfFJYotuyI59zfh966TIQYUF2Id6NR56zpq_Vw=.6b3b5411-e086-45df-8666-2496ac013548@github.com>
 <RO4L3O7d9wghJPWZ5p_GokrNC_uz_TosOqlMI6_b56U=.340658c9-fad8-41bf-8837-244d7d9dd9d1@github.com>
Message-ID: <8arXva3XJTvJpbElEu8ubw6SF58TL2hVlAgoJFZ3_6s=.c6bd79f0-ecd1-4d26-8294-40f8e99bf59c@github.com>

On Fri, 5 Jan 2024 07:05:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> We do have extensive functional tests for compress/expand APIs in [test/jdk/jdk/incubator/vector](https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/incubator/vector)
>
>> Could there be equivalent `expand` tests?
> 
> Here are the performance number for existing [VectorAPI JMH micros.](https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation)
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/4b260814-3d3c-4e9b-b81a-61492ea48cce)
> ![image](https://github.com/openjdk/jdk/assets/59989778/50048281-ad50-44f6-a875-308e02537be2)

Ah, excellent. Thanks for the numbers!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442673797

From epeter at openjdk.org  Fri Jan  5 10:05:27 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Jan 2024 10:05:27 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
Message-ID: <qGw_jW6FX1xT8LDjyq_wurofawY23c5yPMuTn_jFlps=.b31ecc8f-3fef-4018-8f66-a1408a60a4ac@github.com>

On Thu, 4 Jan 2024 13:40:19 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 957:
> 
>> 955:   __ align(CodeEntryAlignment);
>> 956:   StubCodeMark mark(this, "StubRoutines", stub_name);
>> 957:   address start = __ pc();
> 
> Could you please add some comments here why you are filling the data like this?
> Presumably, you are emitting 32 bits and 64 bits respectively, right? So the cells have different size, correct?

Thanks for the comment addition!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1442665042

From duke at openjdk.org  Fri Jan  5 12:38:35 2024
From: duke at openjdk.org (duke)
Date: Fri, 5 Jan 2024 12:38:35 GMT
Subject: Withdrawn: 8319761: Simplify fields of Array VarHandles
In-Reply-To: <Q5dYFkWOttz2PKIJSkHyadSWu53Zbbgn_WKYjFFrjbs=.ebe09205-2433-41dd-9815-a7909cbe51bb@github.com>
References: <Q5dYFkWOttz2PKIJSkHyadSWu53Zbbgn_WKYjFFrjbs=.ebe09205-2433-41dd-9815-a7909cbe51bb@github.com>
Message-ID: <nrknaZyBf7ndZR0Hnjz7TAZFTiNVzSYyVQiB7JHdS5w=.74a0360c-bb13-489b-9d69-c5fb37736656@github.com>

On Sun, 24 Sep 2023 13:17:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. Primitive array VHs are now singletons and no longer need to record their array base and offset in their object themselves.
> 2. Moved Unsafe offset calculation to a utility method, like `index` in VarHandleByteArrayView.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Jan  5 12:50:39 2024
From: duke at openjdk.org (duke)
Date: Fri, 5 Jan 2024 12:50:39 GMT
Subject: Withdrawn: 8316493: Remove the caching fields in AbstractMap
In-Reply-To: <DpNRZsCvDmDfEZ0X-xTKRnwpr3vhgmFTr9IWoveGFbs=.bf85bf6c-97eb-44af-977b-b9909956fa95@github.com>
References: <DpNRZsCvDmDfEZ0X-xTKRnwpr3vhgmFTr9IWoveGFbs=.bf85bf6c-97eb-44af-977b-b9909956fa95@github.com>
Message-ID: <x3rb4ccvuiYEHz6vfyiqPbBKTdtwP_NhbGHIYURhn1A=.a550052e-5e7e-4b42-9470-ff8f19ec51da@github.com>

On Thu, 7 Sep 2023 11:13:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

This pull request has been closed without being integrated.

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

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

From vklang at openjdk.org  Fri Jan  5 14:53:30 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 5 Jan 2024 14:53:30 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
Message-ID: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>

While this might not fix 8314515, it should at least make it more exact.

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

Commit messages:
 - Improving SynchronousQueue Fairness test to only proceed once observing that the previous thread is enqueued as a producer

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

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

From vklang at openjdk.org  Fri Jan  5 14:53:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 5 Jan 2024 14:53:31 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <4rN3L4B6S4Bdi-HhRfW3gZDHW-CmGxy82Z36QmrotII=.7e8019cf-3e36-4b4f-b14f-0891e7030b92@github.com>

On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While this might not fix 8314515, it should at least make it more exact.

@Martin-Buchholz @DougLea while this might not fix https://bugs.openjdk.org/browse/JDK-8314515 it should be more correct than waiting for the thread state to change.

Made it a draft PR to elicit your thoughts :)

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

PR Comment: https://git.openjdk.org/jdk/pull/17082#issuecomment-1852240025

From dl at openjdk.org  Fri Jan  5 14:53:31 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 5 Jan 2024 14:53:31 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <GaAqN3OsKoIx5W-FzyHyr0eRuBrfLNmTVFTiIx0NCtA=.f10da99b-e8ff-4f61-ae34-515193fa008d@github.com>

On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While this might not fix 8314515, it should at least make it more exact.

Yes, it is a bit more fragile (looking for particular methods) but similar to other test improvements (like FJP close tests) that make them more reliable and surprisingly usually a little faster

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

PR Comment: https://git.openjdk.org/jdk/pull/17082#issuecomment-1852273620

From maurizio.cimadamore at oracle.com  Fri Jan  5 15:01:58 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 5 Jan 2024 15:01:58 +0000
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <CAJL5A3k9TK=A8po+ms_Qx9gw8kVCB4=eh4r7+2Z1eF1tF+okcw@mail.gmail.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
 <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>
 <4fa1375a-02e9-45da-a4f2-db7eba1c26e1@oracle.com>
 <CAJL5A3k9TK=A8po+ms_Qx9gw8kVCB4=eh4r7+2Z1eF1tF+okcw@mail.gmail.com>
Message-ID: <8169a24f-b424-4138-aeda-d6cdf084475c@oracle.com>

Hi Glavo,
parsing ld.conf is something that some frameworks do (e.g. JNR). Last 
time I checked there was some concerns in having hotspot bootstrap code 
depending on the results of an external tool, whose output could change 
over time. Currently, IIRC the list of path is just a compiler constant 
(a macro), which is altered on a per distro basis.

As for Panama, note that the SymbolLookup API allows a better way to 
load system libraries, with its SymbolLookup::libraryLookup factory:

https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)

This is essentially a "raw" wrapper around dlopen/dlsym. So, each name 
you can see in `ldconfig -p`, you will be able to load it with this method.

As Sebastian mentioned, the process of loading system libraries is higly 
OS-dependent. On Linux, you have to wrestle with version numbers (e.g. 
GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system 
libraries are not even present in the file-system [1]. So, I'm afraid 
that loading a system library is a more involved process than just 
setting up a bunch of paths correctly - which might work in the 80% 
cases, but still fail in other cases. Overall, the general feeling is 
that System::loadLibrary tries to expose library loading in a 
minimum-common-denominator kind of approach (which is common to a lot of 
JDK APIs), and trying to make that mechanism more flexible might be a 
lost cause, or not have a great return on investment. The raw 
SymbolLookup wrapper shown above bypasses all these issues, and uses 
whatever library lookup mechanism the underlying OS prefers. Advanced 
users should definitively prefer the latter when working with system 
libraries (esp. when doing so using the FFM's Linker).

Maurizio

[1] - 
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes

On 04/01/2024 14:24, Glavo wrote:
> This is the only way I can think of to get the JDK to behave 
> consistently with ld.
> Maybe we should wait and see other developers who are more familiar 
> with this part.
>
> I'm now sending this email to panama-dev as well.
> I think this proposal is of great significance to Panama, as it will 
> make it easier for developers to develop wrappers for platform libraries.

From vklang at openjdk.org  Fri Jan  5 16:25:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 5 Jan 2024 16:25:24 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <hWtvTIuHe-huTgZa11zoC3FMY2XjbL1yxMXRsxx4erI=.738be53f-8062-4eb2-863e-4fb7d38ea807@github.com>

On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While this might not fix 8314515, it should at least make it more exact.

@AlanBateman I think this change is worth making to see if that makes a difference.

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

PR Comment: https://git.openjdk.org/jdk/pull/17082#issuecomment-1878932945

From zjx001202 at gmail.com  Fri Jan  5 16:29:51 2024
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 6 Jan 2024 00:29:51 +0800
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <8169a24f-b424-4138-aeda-d6cdf084475c@oracle.com>
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 <612a0bed-f3cc-4eb8-969f-ab17f6c27873@oracle.com>
 <CAJL5A3niTNZ1CrBxEJBmNPcBaEJysgJQ6wh_vDFjquCWKXgCww@mail.gmail.com>
 <4fa1375a-02e9-45da-a4f2-db7eba1c26e1@oracle.com>
 <CAJL5A3k9TK=A8po+ms_Qx9gw8kVCB4=eh4r7+2Z1eF1tF+okcw@mail.gmail.com>
 <8169a24f-b424-4138-aeda-d6cdf084475c@oracle.com>
Message-ID: <CAJL5A3kWmuwsLksWtaEohRhudtJ5ENwOYMcnnkqbSNpK6Md6Zw@mail.gmail.com>

>
> As for Panama, note that the SymbolLookup API allows a better way to
> load system libraries, with its SymbolLookup::libraryLookup factory:
>
>
> https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)
>
> This is essentially a "raw" wrapper around dlopen/dlsym. So, each name
> you can see in `ldconfig -p`, you will be able to load it with this method.
>

Thanks for the clarification.

As Sebastian mentioned, the process of loading system libraries is higly
> OS-dependent. On Linux, you have to wrestle with version numbers (e.g.
> GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system
> libraries are not even present in the file-system [1]. So, I'm afraid
> that loading a system library is a more involved process than just
> setting up a bunch of paths correctly - which might work in the 80%
> cases, but still fail in other cases. Overall, the general feeling is
> that System::loadLibrary tries to expose library loading in a
> minimum-common-denominator kind of approach (which is common to a lot of
> JDK APIs), and trying to make that mechanism more flexible might be a
> lost cause, or not have a great return on investment. The raw
> SymbolLookup wrapper shown above bypasses all these issues, and uses
> whatever library lookup mechanism the underlying OS prefers. Advanced
> users should definitively prefer the latter when working with system
> libraries (esp. when doing so using the FFM's Linker).
>

Well, it looks more difficult than I thought.
Maybe we could do something simpler, like just add those paths from the
multiarch specification to the default java.library.path.

Glavo

On Fri, Jan 5, 2024 at 11:02?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Glavo,
> parsing ld.conf is something that some frameworks do (e.g. JNR). Last
> time I checked there was some concerns in having hotspot bootstrap code
> depending on the results of an external tool, whose output could change
> over time. Currently, IIRC the list of path is just a compiler constant
> (a macro), which is altered on a per distro basis.
>
> As for Panama, note that the SymbolLookup API allows a better way to
> load system libraries, with its SymbolLookup::libraryLookup factory:
>
>
> https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)
>
> This is essentially a "raw" wrapper around dlopen/dlsym. So, each name
> you can see in `ldconfig -p`, you will be able to load it with this method.
>
> As Sebastian mentioned, the process of loading system libraries is higly
> OS-dependent. On Linux, you have to wrestle with version numbers (e.g.
> GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system
> libraries are not even present in the file-system [1]. So, I'm afraid
> that loading a system library is a more involved process than just
> setting up a bunch of paths correctly - which might work in the 80%
> cases, but still fail in other cases. Overall, the general feeling is
> that System::loadLibrary tries to expose library loading in a
> minimum-common-denominator kind of approach (which is common to a lot of
> JDK APIs), and trying to make that mechanism more flexible might be a
> lost cause, or not have a great return on investment. The raw
> SymbolLookup wrapper shown above bypasses all these issues, and uses
> whatever library lookup mechanism the underlying OS prefers. Advanced
> users should definitively prefer the latter when working with system
> libraries (esp. when doing so using the FFM's Linker).
>
> Maurizio
>
> [1] -
>
> https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes
>
> On 04/01/2024 14:24, Glavo wrote:
> > This is the only way I can think of to get the JDK to behave
> > consistently with ld.
> > Maybe we should wait and see other developers who are more familiar
> > with this part.
> >
> > I'm now sending this email to panama-dev as well.
> > I think this proposal is of great significance to Panama, as it will
> > make it easier for developers to develop wrappers for platform libraries.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240106/06a59aea/attachment-0001.htm>

From jpai at openjdk.org  Fri Jan  5 16:54:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 16:54:22 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <U-FfCnPB1J1iEMs_RrUw6-YVRLpOOckJMx-Fyz6jFHM=.151c0187-ec1a-4e04-921b-f1e79610707b@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

src/java.base/share/classes/sun/nio/ch/Interruptible.java line 38:

> 36:      * is invoked while holding the Thread's interrupt lock. It will typically record
> 37:      * that the I/O operation has been interrupted so that it can be coordinated with
> 38:      * {@code postInterrupt} when it called after releasing the Thread's interrupt

Should have been "when it is called" instead of  "when it called"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443114966

From alanb at openjdk.org  Fri Jan  5 17:04:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Jan 2024 17:04:25 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <U-FfCnPB1J1iEMs_RrUw6-YVRLpOOckJMx-Fyz6jFHM=.151c0187-ec1a-4e04-921b-f1e79610707b@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <U-FfCnPB1J1iEMs_RrUw6-YVRLpOOckJMx-Fyz6jFHM=.151c0187-ec1a-4e04-921b-f1e79610707b@github.com>
Message-ID: <7sPiUtGp8YhbaL61DhcpZH-bf7E82J4FG7iR-ZbDQDQ=.9db73a3b-949e-43b6-8323-3ba5412125c5@github.com>

On Fri, 5 Jan 2024 16:51:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.
>
> src/java.base/share/classes/sun/nio/ch/Interruptible.java line 38:
> 
>> 36:      * is invoked while holding the Thread's interrupt lock. It will typically record
>> 37:      * that the I/O operation has been interrupted so that it can be coordinated with
>> 38:      * {@code postInterrupt} when it called after releasing the Thread's interrupt
> 
> Should have been "when it is called" instead of  "when it called"

Thanks, this is typo there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443123893

From jpai at openjdk.org  Fri Jan  5 17:04:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 17:04:28 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <c62kD9UuYsY05dwba13kRWZ2QzSziomfdqQhqdbrofQ=.7f51b203-089e-4340-95f8-1bf1a8d19f15@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

src/java.base/share/classes/sun/nio/ch/Interruptible.java line 49:

> 47:      * Selector. This method is required to be idempotent.
> 48:      */
> 49:     void postInterrupt();

Should there be any thread safety note/expectations on this method now that it can be potentially called concurrently by multiple threads since it's called outside of the interrupt lock?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443125420

From jpai at openjdk.org  Fri Jan  5 17:25:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 17:25:24 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <N13aeurBswyE1s-TGRH7QoH_TgBHK-8Po9b3lk0E2jY=.8181ad47-ca85-4d0f-833b-3c0994173efd@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 180:

> 178:         Thread me = Thread.currentThread();
> 179:         if (me.isInterrupted()) {
> 180:             interruptor.interrupt(me);

The new javadoc comment on `Interruptor.interrupt(Thread)` states that "This method is invoked while holding the Thread's interrupt lock.", which isn't the case when being invoked from here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443147621

From jpai at openjdk.org  Fri Jan  5 17:33:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 17:33:23 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <iseMn5ImUnb7U5FlvdrjvlmpSod5dn6FnseOU0a2e1g=.5c82abf3-50bc-4231-b451-54aaecc63102@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 107:

> 105:             public void postInterrupt() {
> 106:                 try {
> 107:                     AbstractInterruptibleChannel.this.close();

Before the current change, the `Interruptible` implementation in this class used to call `AbstractInterruptibleChannel.this.implCloseChannel();` whereas now it calls `close()`. Is that an intentional change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443152626

From alanb at openjdk.org  Fri Jan  5 17:33:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Jan 2024 17:33:26 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <iseMn5ImUnb7U5FlvdrjvlmpSod5dn6FnseOU0a2e1g=.5c82abf3-50bc-4231-b451-54aaecc63102@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <iseMn5ImUnb7U5FlvdrjvlmpSod5dn6FnseOU0a2e1g=.5c82abf3-50bc-4231-b451-54aaecc63102@github.com>
Message-ID: <bZmWd0S-soDrom1YvKMh16yAYLp5uSmpQvyVySIzSxY=.215f5ce9-13d5-4f4d-87ac-ea9d60a70a49@github.com>

On Fri, 5 Jan 2024 17:27:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.
>
> src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 107:
> 
>> 105:             public void postInterrupt() {
>> 106:                 try {
>> 107:                     AbstractInterruptibleChannel.this.close();
> 
> Before the current change, the `Interruptible` implementation in this class used to call `AbstractInterruptibleChannel.this.implCloseChannel();` whereas now it calls `close()`. Is that an intentional change?

Yes, this is intentional.

> src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 180:
> 
>> 178:         Thread me = Thread.currentThread();
>> 179:         if (me.isInterrupted()) {
>> 180:             interruptor.interrupt(me);
> 
> The new javadoc comment on `Interruptor.interrupt(Thread)` states that "This method is invoked while holding the Thread's interrupt lock.", which isn't the case when being invoked from here.

This is an internal interface, I can re-phrase the method description to make it clear that this is when Thread.interrupt is called.

> src/java.base/share/classes/sun/nio/ch/Interruptible.java line 49:
> 
>> 47:      * Selector. This method is required to be idempotent.
>> 48:      */
>> 49:     void postInterrupt();
> 
> Should there be any thread safety note/expectations on this method now that it can be potentially called concurrently by multiple threads since it's called outside of the interrupt lock?

This is an internal interface, it's not a general purpose interface that anything outside of the NIO implementation should use. The phrase in the javadoc is meant to make it clear that it may be called more than once, and from several different I/O ops. on the channel.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443153433
PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443154022
PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443155765

From jpai at openjdk.org  Fri Jan  5 17:37:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 17:37:24 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <TOfl-ZOHLNCYVnZTfgysE7DvrmX2tbgChgBzyazyDmg=.4ec1f992-5a98-4a2f-a200-07cc865bed9d@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

src/java.base/share/classes/java/lang/VirtualThread.java line 863:

> 861:             checkAccess();
> 862: 
> 863:             // if current thread is a virtual thread then prevent it from being

Is the use of "current thread" here meant to imply "Thread.currentThread()"? If so, is there a check missing for `Thread.currentThread().isVirtual()` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443160966

From dlutker at openjdk.org  Fri Jan  5 17:46:34 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Fri, 5 Jan 2024 17:46:34 GMT
Subject: [jdk22] RFR: 8322725: (tz) Update Timezone Data to 2023d
Message-ID: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>

Clean backport tzdata 2023d.
`make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

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

Commit messages:
 - Backport 2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc

Changes: https://git.openjdk.org/jdk22/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322725
  Stats: 140 lines in 14 files changed: 94 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jdk22/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/35/head:pull/35

PR: https://git.openjdk.org/jdk22/pull/35

From alanb at openjdk.org  Fri Jan  5 17:50:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Jan 2024 17:50:25 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <TOfl-ZOHLNCYVnZTfgysE7DvrmX2tbgChgBzyazyDmg=.4ec1f992-5a98-4a2f-a200-07cc865bed9d@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <TOfl-ZOHLNCYVnZTfgysE7DvrmX2tbgChgBzyazyDmg=.4ec1f992-5a98-4a2f-a200-07cc865bed9d@github.com>
Message-ID: <_6F0yVdYdkWjRGUTec6MES2uAdX149lvi72lcoAXfFU=.2b5833e8-b2c5-4901-be5b-f9472e504595@github.com>

On Fri, 5 Jan 2024 17:35:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 863:
> 
>> 861:             checkAccess();
>> 862: 
>> 863:             // if current thread is a virtual thread then prevent it from being
> 
> Is the use of "current thread" here meant to imply "Thread.currentThread()"? If so, is there a check missing for `Thread.currentThread().isVirtual()` here?

It's correct. There are two threads, the current thread that is executing the method, plus "this". Serguei is working to change notifyJvmtiDisableSuspend to be a static method (JDK-8322744) to make it clearer that it disable suspend of the current virtual thread rather than the receiver.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443170217

From jpai at openjdk.org  Fri Jan  5 17:50:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 17:50:27 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <_6F0yVdYdkWjRGUTec6MES2uAdX149lvi72lcoAXfFU=.2b5833e8-b2c5-4901-be5b-f9472e504595@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <TOfl-ZOHLNCYVnZTfgysE7DvrmX2tbgChgBzyazyDmg=.4ec1f992-5a98-4a2f-a200-07cc865bed9d@github.com>
 <_6F0yVdYdkWjRGUTec6MES2uAdX149lvi72lcoAXfFU=.2b5833e8-b2c5-4901-be5b-f9472e504595@github.com>
Message-ID: <qpEDwz2oyNTCX6fJFbZXFma02hlS_EmQOP9HyTEXzLs=.7a1598df-386a-4efd-a7c5-3eae58d0ba5a@github.com>

On Fri, 5 Jan 2024 17:42:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Serguei is working to change notifyJvmtiDisableSuspend to be a static method (JDK-8322744) to make it clearer that it disable suspend of the current virtual thread rather than the receiver.

That explains it then. Before commenting, I did check if `notifyJvmtiDisableSuspend` operates on the `Thread.currentThread()` but it was an instance method which ended up being a `native` method and I didn't dig deeper but assumed it works on the thread instance on which it is called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443173235

From jpai at openjdk.org  Fri Jan  5 17:50:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 17:50:22 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <Zbgb11P-39ZX43dNistubAsU1oyTA13dvOZKlpOGMNE=.9ccd7c83-3620-4812-b3f6-bc805c53d287@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

These changes look OK to me.

There are some trivial javadoc comments which you can decide if are worth doing - it's fine by me either way since like you note it is a tightly controlled internal interface.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17219#pullrequestreview-1806509423

From liach at openjdk.org  Fri Jan  5 20:38:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Jan 2024 20:38:26 GMT
Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11]
In-Reply-To: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
References: <DpNRZsCvDmDfEZ0X-xTKRnwpr3vhgmFTr9IWoveGFbs=.bf85bf6c-97eb-44af-977b-b9909956fa95@github.com>
 <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
Message-ID: <oiJlz_tGpUZfqNgUSoDWFQ9iS0UUG0jn_AgG33zMfhg=.0748d4f1-3e09-40bb-acef-d73f3cf7ac38@github.com>

On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into vb-map2
>  - Fix formatting
>  - Remove caching in TreeMap
>  - Remove caching from CHM and CSLM
>  - Move back clone to original position
>  - Reintroduce AbstractMap::clone
>  - Add 'fresh' to implSpec
>  - Remove AbstractMap::clone
>  - Merge master
>  - Merge branch 'master' into vb-map2
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9cce9fe0...b1bfcd17

test/micro/org/openjdk/bench/java/util/HashMapViews.java line 48:

> 46: @Fork(1)
> 47: @State(Scope.Thread)
> 48: public class HashMapViews {

Can we test TreeMap too? WeakHashMap, IdentityHashMap, and EnumMap have specific key requirements that prevents testing unfortunately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1443347052

From mchung at openjdk.org  Fri Jan  5 21:28:28 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Jan 2024 21:28:28 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
Message-ID: <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>

On Wed, 3 Jan 2024 12:36:26 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:
> 
>   StackCounter fix

I think it's okay to split the fix to SplitConstantPool.java and StackCounter.java in a separate PR now.  This PR can go next once reviewed.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 28:

> 26: package java.lang.reflect;
> 27: 
> 28: import java.lang.classfile.*;

Nit:  sort the imports in alphabetical orders.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 112:

> 110:     private static final ClassModel TEMPLATE;
> 111: 
> 112:     private static final Utf8Entry UE_Method;

Nit: good to group this list of static variables by type for netter readability.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 135:

> 133:         var cc = ClassFile.of();
> 134:         var entries = new ArrayList<PoolEntry>(20);
> 135:         var q = new Object() {

It'd be helpful to add a comment to explain what this optimization is doing.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 148:

> 146:             generateLookupAccessor(clb);
> 147:             var cp = clb.constantPool();
> 148:             q.entries = new PoolEntry[] {

line 174-197 must match the order of CP entries being added.

Is there other way to avoid `q.next()` coupling with the order of CP entries in `q.entries`?  Maybe define constants for the indices to `q.entries` such that writing and reading the CP entries from the array using the constant index is easier to read and less error-prone?

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 299:

> 297:     /**
> 298:      * {@return the entries of the given type}
> 299:      * @param type the {@code Class} objects, no primitives nor arrays

Suggestion:

     * @param types the {@code Class} objects, not primitive types nor array types

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 303:

> 301:     private static ClassEntry[] toClassEntries(ConstantPoolBuilder cp, List<Class<?>> types) {
> 302:         var ces = new ClassEntry[types.size()];
> 303:         for (int i = 0; i< ces.length; i++)

Suggestion:

        for (int i = 0; i < ces.length; i++)

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 739:

> 737:             var desc = new StringJoiner("", "(", ")" + returnType.descriptorString());
> 738:             for (var pt : parameterTypes) {
> 739:                 desc.add(pt.descriptorString());

Maybe worth refactor these as `ProxyMethod::toMethodTypeDescriptorString` with the comment to explain why `MethodType::descriptorString` is not used.

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

PR Review: https://git.openjdk.org/jdk/pull/17121#pullrequestreview-1806808189
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443351490
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443352842
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443355763
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443365641
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443371360
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443370121
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1443381525

From liach at openjdk.org  Fri Jan  5 22:58:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Jan 2024 22:58:36 GMT
Subject: RFR: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig [v3]
In-Reply-To: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
Message-ID: <yhFugFVn10iS_nC_9ZYvAjcGN4SYd5vjGy5wMbAP8YE=.e42e1146-98e3-474f-bed9-2ea636c9788a@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 pull request now contains six commits:

 - Fix a few other invalid signatures
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signature-elements
 - Add extra test cases for new bad class signatures
 - Merge branch 'master' into feature/class-signature-elements
 - Merge branch 'master' into feature/class-signature-elements
 - 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig

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

Changes: https://git.openjdk.org/jdk/pull/16514/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16514&range=02
  Stats: 201 lines in 6 files changed: 120 ins; 30 del; 51 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 liach at openjdk.org  Fri Jan  5 23:06:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Jan 2024 23:06:30 GMT
Subject: RFR: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig [v4]
In-Reply-To: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
Message-ID: <wVzbpRlKtCJ-n-nlKwEVZnS449KgyqFsk7EOWpARui8=.f06c5a5e-6a07-4b2c-b86e-9ef5102e9d9b@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 pull request now contains one commit:

  8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig

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

Changes: https://git.openjdk.org/jdk/pull/16514/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16514&range=03
  Stats: 203 lines in 6 files changed: 122 ins; 30 del; 51 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 liach at openjdk.org  Fri Jan  5 23:06:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Jan 2024 23:06:33 GMT
Subject: RFR: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig [v3]
In-Reply-To: <yhFugFVn10iS_nC_9ZYvAjcGN4SYd5vjGy5wMbAP8YE=.e42e1146-98e3-474f-bed9-2ea636c9788a@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
 <yhFugFVn10iS_nC_9ZYvAjcGN4SYd5vjGy5wMbAP8YE=.e42e1146-98e3-474f-bed9-2ea636c9788a@github.com>
Message-ID: <HSgrqpRWT6MvNqK-m-2ugjCfy8T7_vQwEiK71jUrvk4=.3c56b70b-fea1-4c2e-a687-6732862442db@github.com>

On Fri, 5 Jan 2024 22:58:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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 pull request now contains six commits:
> 
>  - Fix a few other invalid signatures
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signature-elements
>  - Add extra test cases for new bad class signatures
>  - Merge branch 'master' into feature/class-signature-elements
>  - Merge branch 'master' into feature/class-signature-elements
>  - 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig

@asotona Could you review this patch, which fixes some of our API's violation of the JVMS, as shown in the tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/16514#issuecomment-1879361294

From mchung at openjdk.org  Fri Jan  5 23:58:22 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Jan 2024 23:58:22 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <cpI1U6NuFEawsga3apAVh2Xe6kU9vbTsC0yWtEAkXws=.05883c49-d650-40ae-a1b3-05ad0906230a@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
 <cpI1U6NuFEawsga3apAVh2Xe6kU9vbTsC0yWtEAkXws=.05883c49-d650-40ae-a1b3-05ad0906230a@github.com>
Message-ID: <RMHHldRRmTIPahcEt8O1Cgu7LSVtmAiaV3FPfcGZ-r0=.16498238-7955-4b01-97a3-3b2f0c00acfe@github.com>

On Thu, 21 Dec 2023 01:33:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 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

Do you think these also cause the performance overhead in converting java.lang.invoke to use ClassFile API (#17108)?

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

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1879397697

From vklang at openjdk.org  Sat Jan  6 00:54:22 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 6 Jan 2024 00:54:22 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <BeqKKKmGVkg3up_CUrC9rQ8nna3u5gFrguMEN1vk3us=.abfb2ae3-2a40-4f37-8507-b1dcde519f71@github.com>

On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While this might not fix 8314515, it should at least make it more exact.

test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 27:

> 25:  * @test
> 26:  * @modules java.base/java.util.concurrent:open
> 27:  * @bug 4992438 6633113

Suggestion:

 * @bug 4992438 6633113 8314515

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17082#discussion_r1443547623

From jpai at openjdk.org  Sat Jan  6 06:02:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 6 Jan 2024 06:02:30 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v3]
In-Reply-To: <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
 <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
Message-ID: <9XI6XY-8q3Fiq954bc9KzljbgDw3GuEjsUcmqTarbJo=.58269b63-7566-43aa-a68b-49c96f875a96@github.com>

On Fri, 5 Jan 2024 09:07:57 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 with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8320699_OutputAnalyzer_progress_logging
>  - Update OutputBuffer.java copyright years
>  - 8320699: Add parameter to skip progress logging of OutputAnalyzer

Still looks fine.

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

Marked as reviewed by jpai (Reviewer).

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

From alanb at openjdk.org  Sat Jan  6 18:27:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Jan 2024 18:27:28 GMT
Subject: Integrated: 8322846: Running with -Djdk.tracePinnedThreads set can
 hang
In-Reply-To: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
References: <zlzD6Jyqfp3V-2oGQ8Q2VOubZpkxxC1gtsbKTruKM7Q=.8deb8444-bbaf-4988-8aa3-c0faa7dd7003@github.com>
Message-ID: <uPhK0WsJCVg3EnEwlJRCSGmY4xj__-1LEfQJXSIsl4Q=.c4f590cc-6cc7-428b-945d-80300b74d9db@github.com>

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.

This pull request has now been integrated.

Changeset: faa9c690
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/faa9c6909dda635eb008b9dada6e06fca47c17d6
Stats:     128 lines in 3 files changed: 100 ins; 12 del; 16 mod

8322846: Running with -Djdk.tracePinnedThreads set can hang

Reviewed-by: jpai

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

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

From liach at openjdk.org  Sun Jan  7 18:26:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 Jan 2024 18:26:31 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
Message-ID: <MwVjDo_5N9V6JoE92A7cvkpLnmz4be9OASLO4bfvD8A=.1129e914-0562-4ff6-a901-33e0f4b77108@github.com>

On Wed, 3 Jan 2024 12:36:26 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:
> 
>   StackCounter fix

Also `StackMapDecoder::initFrameFromLocals(ClassEntry, ...)` can benefit from 2 changes:
1. Iterate MTD by index instead of creating copies
2. Pass ClassEntry from reader/writer constant pool to ObjectVerificationTypeInfoImpl instead of using the temporary pool

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 306:

> 304:                         var cpe = cp.entryByIndex(bcs.getIndexU2());
> 305:                         var nameAndType = opcode == INVOKEDYNAMIC ? ((DynamicConstantPoolEntry)cpe).nameAndType() : ((MemberRefEntry)cpe).nameAndType();
> 306:                         addStackSlot(-countMethodStack(nameAndType.type(), true));

Can use something like:

var mtd = Util.methodTypeSymbol(nameAndType);
addStackSlot(Util.slotSize(mtd.returnType()) - Util.parameterSlots(mtd));

if you stick with MTD.

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

PR Review: https://git.openjdk.org/jdk/pull/17121#pullrequestreview-1807849802
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444049814

From liach at openjdk.org  Sun Jan  7 18:26:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 Jan 2024 18:26:32 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <oz1PEeqMI3xBLfqln3xOV5vILlYQncMe4ZjZWKhwSTM=.3eef4529-81e4-49d4-bd2a-1c30f7338054@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
 <6QJXbG4RyTpE8Xnbsr1NNTuAqokhgKbgbERN6t2VJso=.de1c67b9-8755-4b25-9f85-c92455ff12eb@github.com>
 <oz1PEeqMI3xBLfqln3xOV5vILlYQncMe4ZjZWKhwSTM=.3eef4529-81e4-49d4-bd2a-1c30f7338054@github.com>
Message-ID: <v9JruG3v1PR9hgOUDgZsKkiZiEPEfJSfvJ7JsXEKrTY=.690e31ff-7a15-4be3-86ef-35dc5c658dcc@github.com>

On Wed, 3 Jan 2024 12:25:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> 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.
>
> Original code has been significant in profiler.
> 
> 
> MethodTypeDesc desc = MethodTypeDesc.of(toClassDesc(returnType),
>                     Arrays.stream(parameterTypes).map(ProxyGenerator::toClassDesc).toArray(ClassDesc[]::new));
> 
> 
> 1. each `toClassDesc` builds `descriptorString` and parses/validates it while constructing `ClassDesc`
> 2. `Arrays.stream(...).map(...).toArray(...)` allocates an array
> 3. `MethodTypeDesc.of(...)` clones the array and iterates params to check for void
> 4. `desc.descriptorString()` then finally use the `StringJoiner` 
> 
> Optimized code only joins `descriptorString`, no validations, no streaming, no arrays, no cloning.
> 
> 
> I suggest this patch as this code is considered as performance critical.
> However we can go through `ClassDesc` and `MethodTypeDesc` if not performance critical or if the conversions would be optimized.
> 
> For example better (trusted) paths from `MethodType` to `MethodTypeDescriptor` and from `Class` to `ClassDesc`, avoiding at least validations.

Turns out your approach to avoid MTD here is apparently useless; `MethodTypeDesc` is still created for initializing the local tracker `topLocal` in `DirectCodeBuilder`. In addition, `StackMapDecoder` also uses `methodTypeSymbol` to compute the initial frame.

IMO we should just stay with MTD; the descriptor breakdown happens too often and, from previous benchmarks, descriptor breakdown is actually slow (which gives CF API a small edge over ASM here). But we can still replace the `parameterList()` iteration with index-based iteration to avoid array copies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444049504

From jbhateja at openjdk.org  Mon Jan  8 06:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 8 Jan 2024 06:09:22 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v3]
In-Reply-To: <YtwzrosQJ7O7vNqkuSgzNJWnJMP3jjDY8cNvpPwdeiI=.4b1b7818-39da-4afb-944c-1a2fc8db21f7@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <tfYUCVwnSbUfHmrDgmCCefDbWdPgU7kTzSTr5J2T864=.9d5cdeff-3212-4b38-b3db-b921978a3dc1@github.com>
 <YtwzrosQJ7O7vNqkuSgzNJWnJMP3jjDY8cNvpPwdeiI=.4b1b7818-39da-4afb-944c-1a2fc8db21f7@github.com>
Message-ID: <H-_wtqeXNT1YChXvdOD4-SrgThVvhS9x3VJo0Bg32-g=.cf11a935-04ee-46f2-825d-8ab2ef7325b5@github.com>

On Fri, 5 Jan 2024 10:02:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Thanks for the updates!
> 
> One more idea: Your AVX2 solution has a lot of cost for converting the mask to a permutation. Might it make sense to split this off into a separate vector-node, so that it can float out of a loop if the mask is invariant?

CompressV / ExpandV only accepts two inputs, vector to be operated on and mask under which operation is performed, permute table based implementation is specific to x86 backend implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/17261#issuecomment-1880430502

From jbhateja at openjdk.org  Mon Jan  8 06:09:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 8 Jan 2024 06:09:24 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
 <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
Message-ID: <1GHGK7AGinCMKjFIB5oadUP0jiZrC39Z0hncAS3H-9Y=.eb617125-1f51-4cff-889e-b15321f5c72b@github.com>

On Fri, 5 Jan 2024 09:45:11 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> You are using `VectorMask<Integer> pred = VectorMask.fromLong(ispecies, maskctr++);`. That basically systematically iterates over all masks, which is nice for a correctness test. But that would use different density inside one test run, right? The average over the loop is still at `50%`, correct?
> 
> I was thinking more a run where the percentage over the whole loop is lower than maybe `1%`. That would get us to a point where maybe the branch prediction of non-vectorized code might be faster, what do you think?

An imperative loop compression will check each mask bit to select compressible lane. Therefore mask with low or high density of set bits should show similar performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1444196848

From jbhateja at openjdk.org  Mon Jan  8 06:23:46 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 8 Jan 2024 06:23:46 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v4]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <Vn-zGBfezGTxMFXWYVJIIzVHpKC_cVx6pGb2OkvngAY=.2edd5815-c807-4af8-9b3f-4bffaba6b26c@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

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

  Review suggestions incorporated.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/ea0aa0b4..257a6351

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

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

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

From sspitsyn at openjdk.org  Mon Jan  8 08:03:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 8 Jan 2024 08:03:28 GMT
Subject: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static
Message-ID: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>

The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
One detail to underline is that he intrinsic implementation needs to use the argument #0 instead of #1.

Testing:
- The mach5 tiers 1-6 show no regressions

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

Commit messages:
 - 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

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

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

From pminborg at openjdk.org  Mon Jan  8 08:23:31 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 8 Jan 2024 08:23:31 GMT
Subject: Integrated: 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: <bMAHYmRZOSxohQNSaFocKeA9E_Jhf2f9HQZlokzi0SI=.42cc4217-4cdb-4fbe-9336-540ea81d75d7@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.

This pull request has now been integrated.

Changeset: 7edd10e5
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7edd10e5fa71dafbbad23455553b7f5ff0a75ac9
Stats:     239 lines in 13 files changed: 200 ins; 21 del; 18 mod

8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

Reviewed-by: mcimadamore

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

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

From alanb at openjdk.org  Mon Jan  8 09:04:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Jan 2024 09:04:57 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock [v2]
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <erE3oAxJqgcfoxBFdSdbdk4WkX3vsDNoYSYEE124mwA=.c451deed-ee98-43a4-a7e2-7cdb0261c8af@github.com>

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

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:

 - Make sun.nio.ch.Interruptible's javadoc a bit clearer
 - Merge
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17219/files
  - new: https://git.openjdk.org/jdk/pull/17219/files/e402582d..634cd876

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

  Stats: 4903 lines in 422 files changed: 2589 ins; 930 del; 1384 mod
  Patch: https://git.openjdk.org/jdk/pull/17219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17219/head:pull/17219

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

From alanb at openjdk.org  Mon Jan  8 09:04:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Jan 2024 09:04:58 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock [v2]
In-Reply-To: <bZmWd0S-soDrom1YvKMh16yAYLp5uSmpQvyVySIzSxY=.215f5ce9-13d5-4f4d-87ac-ea9d60a70a49@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <iseMn5ImUnb7U5FlvdrjvlmpSod5dn6FnseOU0a2e1g=.5c82abf3-50bc-4231-b451-54aaecc63102@github.com>
 <bZmWd0S-soDrom1YvKMh16yAYLp5uSmpQvyVySIzSxY=.215f5ce9-13d5-4f4d-87ac-ea9d60a70a49@github.com>
Message-ID: <2__yzgpgSnyrDV_DEY4c1wF3z35_nDvp7hAG99Acrow=.11c4d4db-8ce4-4c25-8948-d3f8b8177bdf@github.com>

On Fri, 5 Jan 2024 17:28:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 180:
>> 
>>> 178:         Thread me = Thread.currentThread();
>>> 179:         if (me.isInterrupted()) {
>>> 180:             interruptor.interrupt(me);
>> 
>> The new javadoc comment on `Interruptor.interrupt(Thread)` states that "This method is invoked while holding the Thread's interrupt lock.", which isn't the case when being invoked from here.
>
> This is an internal interface, I can re-phrase the method description to make it clear that this is when Thread.interrupt is called.

I've update the method descriptions in sun.nio.ch.Interruptible and hopefully it is a bit clearer now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1444309663

From jpai at openjdk.org  Mon Jan  8 09:28:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 09:28:28 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock [v2]
In-Reply-To: <erE3oAxJqgcfoxBFdSdbdk4WkX3vsDNoYSYEE124mwA=.c451deed-ee98-43a4-a7e2-7cdb0261c8af@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <erE3oAxJqgcfoxBFdSdbdk4WkX3vsDNoYSYEE124mwA=.c451deed-ee98-43a4-a7e2-7cdb0261c8af@github.com>
Message-ID: <OtPu1VGAbKoiNpYbPanxTOpNCuFDvEVuAjKGhwoQ2-8=.98df023f-409d-462e-b546-ef36c8023b67@github.com>

On Mon, 8 Jan 2024 09:04:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.
>
> 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:
> 
>  - Make sun.nio.ch.Interruptible's javadoc a bit clearer
>  - Merge
>  - Merge
>  - Initial commit

Thank you Alan for the updated javadoc. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17219#pullrequestreview-1808467345

From qamai at openjdk.org  Mon Jan  8 10:23:22 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Jan 2024 10:23:22 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v3]
In-Reply-To: <H-_wtqeXNT1YChXvdOD4-SrgThVvhS9x3VJo0Bg32-g=.cf11a935-04ee-46f2-825d-8ab2ef7325b5@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <tfYUCVwnSbUfHmrDgmCCefDbWdPgU7kTzSTr5J2T864=.9d5cdeff-3212-4b38-b3db-b921978a3dc1@github.com>
 <YtwzrosQJ7O7vNqkuSgzNJWnJMP3jjDY8cNvpPwdeiI=.4b1b7818-39da-4afb-944c-1a2fc8db21f7@github.com>
 <H-_wtqeXNT1YChXvdOD4-SrgThVvhS9x3VJo0Bg32-g=.cf11a935-04ee-46f2-825d-8ab2ef7325b5@github.com>
Message-ID: <6ipaD7eRW4J37zaeFEKVf2LUVE3C0LmZmoAeePCG2PE=.7bb8ff9a-638e-4e7f-bea2-a40a424004f0@github.com>

On Mon, 8 Jan 2024 06:06:22 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks for the updates!
>> 
>> One more idea: Your AVX2 solution has a lot of cost for converting the mask to a permutation. Might it make sense to split this off into a separate vector-node, so that it can float out of a loop if the mask is invariant?
>
>> Thanks for the updates!
>> 
>> One more idea: Your AVX2 solution has a lot of cost for converting the mask to a permutation. Might it make sense to split this off into a separate vector-node, so that it can float out of a loop if the mask is invariant?
> 
> CompressV / ExpandV only accepts two inputs, vector to be operated on and mask under which operation is performed, permute table based implementation is specific to x86 backend implementation.

@jatin-bhateja I think you can expand them in the matcher into several `MachNode`s that will get scheduled separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/17261#issuecomment-1880724248

From epeter at openjdk.org  Mon Jan  8 10:36:22 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Jan 2024 10:36:22 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v4]
In-Reply-To: <Vn-zGBfezGTxMFXWYVJIIzVHpKC_cVx6pGb2OkvngAY=.2edd5815-c807-4af8-9b3f-4bffaba6b26c@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <Vn-zGBfezGTxMFXWYVJIIzVHpKC_cVx6pGb2OkvngAY=.2edd5815-c807-4af8-9b3f-4bffaba6b26c@github.com>
Message-ID: <7x_AB9EVEuOwt5SldzxWgEKIqDG3ovw6ngBCjL4XKzU=.c8c79b8a-3023-42f5-b8d6-9ed6183d97f8@github.com>

On Mon, 8 Jan 2024 06:23:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

Exactly, like @merykitty suggests: you can do a platform-dependent expansion.

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1808218664

From epeter at openjdk.org  Mon Jan  8 10:36:23 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Jan 2024 10:36:23 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <YKyGqXZGEtLDYYiOf2m4C-Bj10hPlKu3iQBEG_U6D54=.e7ed83dd-0ef4-4e77-9c65-dd0426e2cd53@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <qGw_jW6FX1xT8LDjyq_wurofawY23c5yPMuTn_jFlps=.b31ecc8f-3fef-4018-8f66-a1408a60a4ac@github.com>
 <YKyGqXZGEtLDYYiOf2m4C-Bj10hPlKu3iQBEG_U6D54=.e7ed83dd-0ef4-4e77-9c65-dd0426e2cd53@github.com>
Message-ID: <_IaxcZYOfUasnC-VujuwT4nFF3KVdEcKU2Pt92o5UO8=.bc760b2f-8ce9-4021-beb8-bfb19827cce3@github.com>

On Fri, 5 Jan 2024 09:35:34 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Thanks for the comment addition!
>
> Improvement suggestion:
> For a vector with 8 ints, we get `2^8 = 256` many bit patterns for the mask. The table has a row for each `mask` value, consisting of 8 ints, which provide the valid permute index corresponding to set bit position in the `mask`, or a -1 (default) value.

@jatin-bhateja thanks for the update!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1444256359

From epeter at openjdk.org  Mon Jan  8 10:36:25 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Jan 2024 10:36:25 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <1GHGK7AGinCMKjFIB5oadUP0jiZrC39Z0hncAS3H-9Y=.eb617125-1f51-4cff-889e-b15321f5c72b@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
 <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
 <1GHGK7AGinCMKjFIB5oadUP0jiZrC39Z0hncAS3H-9Y=.eb617125-1f51-4cff-889e-b15321f5c72b@github.com>
Message-ID: <cki6CtBfBxWRlqaBGdfIgfwTOBMxtt8CSefU0WVZjxI=.2752863f-2922-42cc-b3b0-63d39f29889a@github.com>

On Mon, 8 Jan 2024 06:06:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> You are using `VectorMask<Integer> pred = VectorMask.fromLong(ispecies, maskctr++);`.
>> That basically systematically iterates over all masks, which is nice for a correctness test.
>> But that would use different density inside one test run, right? The average over the loop is still at `50%`, correct?
>> 
>> I was thinking more a run where the percentage over the whole loop is lower than maybe `1%`. That would get us to a point where maybe the branch prediction of non-vectorized code might be faster, what do you think?
>
>> You are using `VectorMask<Integer> pred = VectorMask.fromLong(ispecies, maskctr++);`. That basically systematically iterates over all masks, which is nice for a correctness test. But that would use different density inside one test run, right? The average over the loop is still at `50%`, correct?
>> 
>> I was thinking more a run where the percentage over the whole loop is lower than maybe `1%`. That would get us to a point where maybe the branch prediction of non-vectorized code might be faster, what do you think?
> 
> An imperative loop for compression will check each mask bit to select compressible lane. Therefore mask with low or high density of set bits should show similar performance.

Yes, IF it is vectorized, then there is no difference between high and low density. My concern was more if vectorization is preferrable over the scalar alternative in the low-density case, where branch prediction is more stable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1444257535

From asotona at openjdk.org  Mon Jan  8 11:41:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 11:41:24 GMT
Subject: RFR: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig [v4]
In-Reply-To: <wVzbpRlKtCJ-n-nlKwEVZnS449KgyqFsk7EOWpARui8=.f06c5a5e-6a07-4b2c-b86e-9ef5102e9d9b@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
 <wVzbpRlKtCJ-n-nlKwEVZnS449KgyqFsk7EOWpARui8=.f06c5a5e-6a07-4b2c-b86e-9ef5102e9d9b@github.com>
Message-ID: <29zEQ23lx0wqPTXz_cx872tlG_ZGuAuGdlaCwe8E-0E=.f004f965-ce19-40b3-9cde-234904b9824a@github.com>

On Fri, 5 Jan 2024 23:06:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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 pull request now contains one commit:
> 
>   8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig

The patch looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16514#pullrequestreview-1808894111

From asotona at openjdk.org  Mon Jan  8 13:22:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 13:22:23 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <MwVjDo_5N9V6JoE92A7cvkpLnmz4be9OASLO4bfvD8A=.1129e914-0562-4ff6-a901-33e0f4b77108@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <MwVjDo_5N9V6JoE92A7cvkpLnmz4be9OASLO4bfvD8A=.1129e914-0562-4ff6-a901-33e0f4b77108@github.com>
Message-ID: <yfiW5tOuBNOGt8IMp3txEteKwq_juGQwR7bpiwMoI7g=.140a99ea-ffe8-4372-b5e4-e2812dfffe01@github.com>

On Sun, 7 Jan 2024 18:18:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StackCounter fix
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 306:
> 
>> 304:                         var cpe = cp.entryByIndex(bcs.getIndexU2());
>> 305:                         var nameAndType = opcode == INVOKEDYNAMIC ? ((DynamicConstantPoolEntry)cpe).nameAndType() : ((MemberRefEntry)cpe).nameAndType();
>> 306:                         addStackSlot(-countMethodStack(nameAndType.type(), true));
> 
> Can use something like:
> 
> var mtd = Util.methodTypeSymbol(nameAndType);
> addStackSlot(Util.slotSize(mtd.returnType()) - Util.parameterSlots(mtd));
> 
> if you stick with MTD.

Calculation of MTD for each method invocation is extremely ineffective way to just count the size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444624257

From sundar at openjdk.org  Mon Jan  8 13:31:36 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 8 Jan 2024 13:31:36 GMT
Subject: RFR: 8310995: missing @since tags in 36 jdk.dynalink classes
Message-ID: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>

Adding missing "@ since 9" in javadoc comment of the public classes, interfaces and packages of the jdk.dynalink module.

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

Commit messages:
 - 8310995: missing @since tags in 36 jdk.dynalink classes

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

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

From jlaskey at openjdk.org  Mon Jan  8 13:31:37 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 Jan 2024 13:31:37 GMT
Subject: RFR: 8310995: missing @since tags in 36 jdk.dynalink classes
In-Reply-To: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
References: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
Message-ID: <r-2aM5i2CYf6L-SmAD7et5pLD4j3AeioSW7cC6nv4Q8=.31b51ef4-e5cd-4231-9833-e2978fce5262@github.com>

On Mon, 8 Jan 2024 13:24:55 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding missing "@ since 9" in javadoc comment of the public classes, interfaces and packages of the jdk.dynalink module.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17305#pullrequestreview-1809103393

From asotona at openjdk.org  Mon Jan  8 13:42:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 13:42:24 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
Message-ID: <RTydlEOFQ429PeQcEi9jy5tMNi2wJFzizMYp4hqbgcU=.964abd77-6cf8-4dc0-9a07-d67b2b66ab5c@github.com>

On Wed, 3 Jan 2024 12:36:26 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:
> 
>   StackCounter fix

I've separated ClassFile API performance related improvements into
#17306

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

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1881026433

From asotona at openjdk.org  Mon Jan  8 13:43:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 13:43:58 GMT
Subject: RFR: 8323183: ClassFile API performance improvements
Message-ID: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>

ClassFile API performance related improvements have been separated from #17121 into this PR.

These improvements are important to minimize performance regression of
8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121

Please review.

Thanks,
Adam

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

Commit messages:
 - Revert "8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes"
 - Revert "performance improvements"
 - Revert "performance improvements"
 - Revert "performance improvements"
 - StackCounter fix
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
 - minor StackCounter fix
 - applied the recommended changes
 - performance improvements
 - SplitConstantPool performance fix
 - ... and 4 more: https://git.openjdk.org/jdk/compare/2611a49e...bb2cf21c

Changes: https://git.openjdk.org/jdk/pull/17306/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17306&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323183
  Stats: 92 lines in 2 files changed: 57 ins; 14 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/17306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17306/head:pull/17306

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

From rgiulietti at openjdk.org  Mon Jan  8 13:48:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 Jan 2024 13:48:06 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@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 15 additional commits since the last revision:

 - Merge branch 'master' into 8275338
 - Simplified event messages.
   Remove ckecker allocation.
 - Corrected @Label of event and of field.
 - Removed @module from test.
 - 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.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/3fae3b44...9ca1f36d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/91523c67..9ca1f36d

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

  Stats: 6465 lines in 501 files changed: 3228 ins; 1677 del; 1560 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 asotona at openjdk.org  Mon Jan  8 13:52:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 13:52:37 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v8]
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: <vGQ0PvrcbxeW1YLaofs5I0_yi4uMCFP3C1d6M7ouYEg=.4d9f3fef-aca4-406e-8579-abacec8834f8@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 six additional commits since the last revision:

 - Revert "StackCounter performance boost"
   
   This reverts commit 0dc63d4edf40fd9458fbfa0c7661d57ed0022981.
 - Revert "SplitConstantPool performance fix"
   
   This reverts commit b7a60ae944983224e3b4c097576c496351394fe0.
 - Revert "applied the recommended changes"
   
   This reverts commit 7d0da2c0190c27f8e2cf89557e31f5d16ab4950e.
 - Revert "minor StackCounter fix"
   
   This reverts commit 41e879348c8f2ea70b25119e65527b81281c33ac.
 - Revert "Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java"
   
   This reverts commit c8f1d304358e19872450cd29449d82675f9bbe3e.
 - Revert "StackCounter fix"
   
   This reverts commit c6b761a157e66ccba30df68efa2849a92371acf2.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/c6b761a1..2e50f842

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

  Stats: 92 lines in 2 files changed: 14 ins; 57 del; 21 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  Mon Jan  8 14:05:29 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 14:05:29 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <v9JruG3v1PR9hgOUDgZsKkiZiEPEfJSfvJ7JsXEKrTY=.690e31ff-7a15-4be3-86ef-35dc5c658dcc@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
 <6QJXbG4RyTpE8Xnbsr1NNTuAqokhgKbgbERN6t2VJso=.de1c67b9-8755-4b25-9f85-c92455ff12eb@github.com>
 <oz1PEeqMI3xBLfqln3xOV5vILlYQncMe4ZjZWKhwSTM=.3eef4529-81e4-49d4-bd2a-1c30f7338054@github.com>
 <v9JruG3v1PR9hgOUDgZsKkiZiEPEfJSfvJ7JsXEKrTY=.690e31ff-7a15-4be3-86ef-35dc5c658dcc@github.com>
Message-ID: <2-xphmsYjyTRINcw0jmNz2eVbLyVzNUndA7y_a0WP90=.99deb010-2929-4670-abb2-333eda128a2a@github.com>

On Sun, 7 Jan 2024 18:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Original code has been significant in profiler.
>> 
>> 
>> MethodTypeDesc desc = MethodTypeDesc.of(toClassDesc(returnType),
>>                     Arrays.stream(parameterTypes).map(ProxyGenerator::toClassDesc).toArray(ClassDesc[]::new));
>> 
>> 
>> 1. each `toClassDesc` builds `descriptorString` and parses/validates it while constructing `ClassDesc`
>> 2. `Arrays.stream(...).map(...).toArray(...)` allocates an array
>> 3. `MethodTypeDesc.of(...)` clones the array and iterates params to check for void
>> 4. `desc.descriptorString()` then finally use the `StringJoiner` 
>> 
>> Optimized code only joins `descriptorString`, no validations, no streaming, no arrays, no cloning.
>> 
>> 
>> I suggest this patch as this code is considered as performance critical.
>> However we can go through `ClassDesc` and `MethodTypeDesc` if not performance critical or if the conversions would be optimized.
>> 
>> For example better (trusted) paths from `MethodType` to `MethodTypeDescriptor` and from `Class` to `ClassDesc`, avoiding at least validations.
>
> Turns out your approach to avoid MTD here is apparently useless; `MethodTypeDesc` is still created for initializing the local tracker `topLocal` in `DirectCodeBuilder`. In addition, `StackMapDecoder` also uses `methodTypeSymbol` to compute the initial frame.
> 
> IMO we should just stay with MTD; the descriptor breakdown happens too often and, from previous benchmarks, descriptor breakdown is actually slow (which gives CF API a small edge over ASM here). But we can still replace the `parameterList()` iteration with index-based iteration to avoid array copies.

Right, there are still so many conversions.
I'll revert the custom code to simplify further optimizations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444690465

From asotona at openjdk.org  Mon Jan  8 14:05:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 14:05:27 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
Message-ID: <yNCW_PP-Ww5EVo6-9ZrEt5P24N4XcsIYFOfdQgwYTTk=.ae80dad9-06c5-42b1-b9e5-45e6260993ab@github.com>

On Fri, 5 Jan 2024 20:43:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StackCounter fix
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 28:
> 
>> 26: package java.lang.reflect;
>> 27: 
>> 28: import java.lang.classfile.*;
> 
> Nit:  sort the imports in alphabetical orders.

Will fix, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444693996

From asotona at openjdk.org  Mon Jan  8 14:08:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 14:08:26 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
Message-ID: <ewGVpYR_5_5NShtJwjp3j81Skav0ZUU49qc7lcprGS0=.fcd11cba-68bb-4a59-86a2-bc903a0093a0@github.com>

On Fri, 5 Jan 2024 20:45:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StackCounter fix
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 112:
> 
>> 110:     private static final ClassModel TEMPLATE;
>> 111: 
>> 112:     private static final Utf8Entry UE_Method;
> 
> Nit: good to group this list of static variables by type for netter readability.

yes, will group it, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444697655

From mcimadamore at openjdk.org  Mon Jan  8 14:17:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 Jan 2024 14:17:22 GMT
Subject: RFR: 8323183: ClassFile API performance improvements
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <pLJgbVg9uWvIf9tF-SJT-uQaUobZyvqyoXHGngc7Who=.8eeeb8fc-e300-4744-9293-ad357ac6d8aa@github.com>

On Mon, 8 Jan 2024 13:38:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 367:

> 365:                         if (subReturn) {
> 366:                             return switch (descriptor.charAt(cur++)) {
> 367:                                 case 'Z', 'B', 'C', 'S', 'I', 'F', '[', 'L' -> count - 1;

What if the return type is an array?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1444711725

From mcimadamore at openjdk.org  Mon Jan  8 14:17:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 Jan 2024 14:17:24 GMT
Subject: RFR: 8323183: ClassFile API performance improvements
In-Reply-To: <pLJgbVg9uWvIf9tF-SJT-uQaUobZyvqyoXHGngc7Who=.8eeeb8fc-e300-4744-9293-ad357ac6d8aa@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <pLJgbVg9uWvIf9tF-SJT-uQaUobZyvqyoXHGngc7Who=.8eeeb8fc-e300-4744-9293-ad357ac6d8aa@github.com>
Message-ID: <oc3fO1dVTgPxKi8IZZWpLOoDKcaNb0sBNZkgHg0LqtQ=.c4391213-246a-4b24-a61e-be8ca85b98e2@github.com>

On Mon, 8 Jan 2024 14:14:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 367:
> 
>> 365:                         if (subReturn) {
>> 366:                             return switch (descriptor.charAt(cur++)) {
>> 367:                                 case 'Z', 'B', 'C', 'S', 'I', 'F', '[', 'L' -> count - 1;
> 
> What if the return type is an array?

Ah nvm, I see you subtract -1 there

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1444712392

From asotona at openjdk.org  Mon Jan  8 14:21:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 14:21:26 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
Message-ID: <W8diTF0FWpVIzyedbQCviGW3EOsR4gLRJ3rIOlvjSiE=.b9b10369-f92e-4c77-b187-9f1d928cf0aa@github.com>

On Fri, 5 Jan 2024 20:50:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StackCounter fix
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 135:
> 
>> 133:         var cc = ClassFile.of();
>> 134:         var entries = new ArrayList<PoolEntry>(20);
>> 135:         var q = new Object() {
> 
> It'd be helpful to add a comment to explain what this optimization is doing.

Yes, I'll add an explanation comment, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444717838

From mcimadamore at openjdk.org  Mon Jan  8 14:23:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 Jan 2024 14:23:23 GMT
Subject: RFR: 8323183: ClassFile API performance improvements
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <3zKfr4flD-Jd5ZC1zezEXPgYjF3bvVy6oUTO9D6LZgU=.2bd0d726-fb24-412a-9acb-adae4c820621@github.com>

On Mon, 8 Jan 2024 13:38:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 338:

> 336:     }
> 337: 
> 338:     private static int countMethodStack(Utf8Entry descriptor, boolean subReturn) {

Since we use this for both locals and stack, perhaps "countMethodSlots" would be better? And maybe the "subReturn" could be a flag to switch between locals/stack

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 417:

> 415:                 bcs.bci,
> 416:                 methodName,
> 417:                 MethodTypeDesc.ofDescriptor(methodDesc.stringValue()).displayDescriptor()));

This seems unrelated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1444719273
PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1444721284

From asotona at openjdk.org  Mon Jan  8 14:28:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 14:28:37 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v9]
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: <aTXU4_FAJXMJBFlyO8jhTlf1mD_iWGAolb-JmMl_8TA=.0a591954-73b9-439f-9555-4ece169bfcfb@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:

 - Apply suggestions from code review
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - applied suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/2e50f842..80340914

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

  Stats: 41 lines in 1 file changed: 17 ins; 14 del; 10 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  Mon Jan  8 14:28:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 14:28:40 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
Message-ID: <aNn1kN4RKo1blBvJRrpPeaIScXJiKUkLnkQ94Qki_2E=.ee6ad732-f1d1-4225-b0fe-f70556a1e15f@github.com>

On Fri, 5 Jan 2024 21:23:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StackCounter fix
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 739:
> 
>> 737:             var desc = new StringJoiner("", "(", ")" + returnType.descriptorString());
>> 738:             for (var pt : parameterTypes) {
>> 739:                 desc.add(pt.descriptorString());
> 
> Maybe worth refactor these as `ProxyMethod::toMethodTypeDescriptorString` with the comment to explain why `MethodType::descriptorString` is not used.

I've decided to revert this custom optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444732383

From liach at openjdk.org  Mon Jan  8 14:46:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Jan 2024 14:46:28 GMT
Subject: RFR: 8323183: ClassFile API performance improvements
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <WwYJjRNMnrCwIgK37KydJt0I_8R5TFMgBYyfy5ujMvk=.326b0626-259d-4cf4-aa50-1ce0f21ffe6a@github.com>

On Mon, 8 Jan 2024 13:38:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

You need to update the slot counting from `DirectCodeBuilder` and `StackMapDecoder` to fully avoid creating any MethodTypeDesc.

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

PR Comment: https://git.openjdk.org/jdk/pull/17306#issuecomment-1881145755

From jpai at openjdk.org  Mon Jan  8 14:50:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 14:50:40 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
Message-ID: <icMYzKHUzFqcozVLLYlNzaEeeULO1jxdVO1BszCcSdY=.26e6cc92-83aa-4eb3-85f7-9ca578a753a1@github.com>

On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s 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

Hello Eirik, I had a look at this one today. The motivation behind this change appears to be the statement in the specification which says:


4.3.9  Data descriptor:

        crc-32                          4 bytes
        compressed size                 4 bytes
        uncompressed size               4 bytes

      4.3.9.1 This descriptor MUST exist if bit 3 of the general
      purpose bit flag is set.
      ...
      For ZIP64(tm) format archives, the compressed and uncompressed 
      sizes are 8 bytes each.

      4.3.9.2 When compressing files, compressed and uncompressed sizes 
      SHOULD be stored in ZIP64 format (as 8 byte values) when a 
      file's size exceeds 0xFFFFFFFF.   However ZIP64 format MAY be 
      used regardless of the size of a file.  When extracting, if 
      the zip64 extended information extra field is present for 
      the file the compressed and uncompressed sizes will be 8
      byte values.  


Effectively, this change is proposing to enhance the `java.util.zip.ZipInputStream` to allow for it to parse some more zip/jar files out there, which it currently wouldn't be parsing, even if the spec allowed for such zip files.

Looking through this proposed change, this change only affects `DEFLATED` entries and doesn't impact `STORED` entries. Furthermore, this change affects only those `DEFLATED` entries which have a data descriptor (understandly).

What's being done in this change is that, in a zip/jar file, for each `DEFLATED` entry which has a data descriptor, we now have an additional logic which decides whether we read the compressed/uncompressed sizes in the data descriptor as 4 bytes or as 8 bytes each. Before this change we used to read them as 8 bytes only when the `Inflater` (for that entry) told us that it had dealt with more than `0xFFFFFFFFL` bytes of data for that entry (indicating that this is zip64 entry). With the current proposed change, we not only rely on the `Inflater` for this decision but also rely on `ZipEntry` itself to tell us whether to read 8 bytes or 4 bytes each.

Given this context, I've looked through the changes and I think some additional changes are needed to prevent some potential issues with this proposal. I've added those comments inline.

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

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

From jpai at openjdk.org  Mon Jan  8 14:56:42 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 14:56:42 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
Message-ID: <X7KSSEKO8qGKvIUMVn7noyWD5GV3wq2HiuGjDjaM194=.21b05cfe-3549-4cc3-b7bc-e22df49070f9@github.com>

On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s 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

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 581:

> 579:         if ((flag & 8) == 8) {
> 580:             /* "Data Descriptor" present */
> 581:             if (hasZip64Extra(e) ||

I think it would be better to change the ordering of this boolean conditions. Instead of the current proposed:


if (hasZip64Extra(e) ||
    inf.getBytesWritten() > ZIP64_MAGICVAL ||
    inf.getBytesRead() > ZIP64_MAGICVAL) {


the new condition being introduced here - the `hasZip64Extra(e)` should be at the end:


if (inf.getBytesWritten() > ZIP64_MAGICVAL ||
    inf.getBytesRead() > ZIP64_MAGICVAL ||
    hasZip64Extra(e)) {



That way the chances of this change running additional code (and thus any unexpected semantic change) for existing zip/jar entries which the Inflater already considers as zip64 is avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1444777271

From jpai at openjdk.org  Mon Jan  8 15:02:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 15:02:37 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
Message-ID: <8dI73YzCb0e2jUtDGocyWiyiVqt5pz_Wwma0ELUoJNs=.f056ed16-7cb1-4a30-93d7-0ea40ca6501a@github.com>

On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s 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

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 692:

> 690:     private static boolean isZip64ExtBlockSizeValid(int blockSize) {
> 691:         // Uncompressed and compressed size fields are 8 bytes each
> 692:         return blockSize == 16;

I'm not following this check. As far as I can see the `blockSize` being passed to this method is the size of the zip64 extra entry and as per the spec:


4.5.3 -Zip64 Extended Information Extra Field (0x0001):

      The following is the layout of the zip64 extended 
      information "extra" block. 

      ....

        Value      Size       Description
        -----      ----       -----------
(ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
        Size       2 bytes    Size of this "extra" block
        Original 
        Size       8 bytes    Original uncompressed file size
        Compressed
        Size       8 bytes    Size of compressed data
        Relative Header
        Offset     8 bytes    Offset of local header record
        Disk Start
        Number     4 bytes    Number of the disk on which
                              this file starts 

So shouldn't it be 8 + 8 + 8 + 4 = 28 bytes and not 16 bytes? Did I misunderstand the code or the spec?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1444786479

From duke at openjdk.org  Mon Jan  8 15:04:42 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 8 Jan 2024 15:04:42 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int)
Message-ID: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>

The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.

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

Commit messages:
 - Merge branch 'openjdk:master' into patch-BigIntegerDivision
 - Implementation of divWord(long, int) changed

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

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

From jpai at openjdk.org  Mon Jan  8 15:07:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 15:07:32 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
Message-ID: <GwoKrY4yXDACm2cyzqpGvUFe-Ph-TpEtT1fqauSSC40=.9bfc81e0-2f88-4833-aa59-e43b8da6ebc5@github.com>

On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s 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

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 654:

> 652:      * data contained no Zip64 field.
> 653:      */
> 654:     private boolean hasZip64Extra(ZipEntry e) throws IOException {

Given what this method does, I think it shouldn't throw an IOException (or any other exception for that matter), should strictly return true or false. I haven't imported this code locally, but as far as I can see in its implementation, there doesn't seem to be anything that throws a checked IOException, so perhaps this throws is already redundant?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1444794521

From jpai at openjdk.org  Mon Jan  8 15:16:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 15:16:31 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
Message-ID: <i5Q-IOQnUJFAYHDQVmH8k-dhAoTFwlVwMEy1esLWxFY=.26f07aef-77a2-448a-9e0b-7bc469707d7a@github.com>

On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s 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

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 659:

> 657:         if (extra != null && extra.length > fixedSize) {
> 658:             for (int i = 0; i < extra.length;) {
> 659:                 int id = get16(extra, i);

This and other similar calls in this new method have a potential to throw an `ArrayIndexOutOfBoundsException` because we can't trust the `byte[]` returned by the `ZipEntry.getExtra()` call to be actually having the right amount of extra block data. The private `hasMagic` method in  `java.util.jar.JarOutputStream` has an example where we catch the `ArrayIndexOutOfBoundsException` when dealing with the extra data, we should do similar here and return `false`.

(More on the trustworthiness of that byte[] value returned by `ZipEntry.getExtra()` as a separate comment)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1444806425

From asotona at openjdk.org  Mon Jan  8 15:28:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 15:28:50 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
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: <fEOSmdpqGvSjhneA4HwwnUDRazCfKk-URTfHrU5kWEo=.4748c0b6-e25c-4d41-ae94-d6b93f20acbd@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:

  initialization of template entries by index

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/80340914..e9bf7d57

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

  Stats: 100 lines in 1 file changed: 39 ins; 30 del; 31 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  Mon Jan  8 15:28:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 15:28:53 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <LBbEXoKVc9pYfsCmeX30uCmpa8jvELYvceNup_jMpM8=.99c4617f-30dc-458d-afbf-91a239160039@github.com>
Message-ID: <7sUJbvrg_VFj_oH2Cl8MvYFtwQkHihR9cfnAJzkF6-4=.363c290c-4342-4b82-a425-305fa412919e@github.com>

On Fri, 5 Jan 2024 21:03:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StackCounter fix
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 148:
> 
>> 146:             generateLookupAccessor(clb);
>> 147:             var cp = clb.constantPool();
>> 148:             q.entries = new PoolEntry[] {
> 
> line 174-197 must match the order of CP entries being added.
> 
> Is there other way to avoid `q.next()` coupling with the order of CP entries in `q.entries`?  Maybe define constants for the indices to `q.entries` such that writing and reading the CP entries from the array using the constant index is easier to read and less error-prone?

I've rewritten the initialization to use indexes inside an array.
Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1444825858

From asotona at openjdk.org  Mon Jan  8 15:34:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 15:34:23 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <RMHHldRRmTIPahcEt8O1Cgu7LSVtmAiaV3FPfcGZ-r0=.16498238-7955-4b01-97a3-3b2f0c00acfe@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
 <cpI1U6NuFEawsga3apAVh2Xe6kU9vbTsC0yWtEAkXws=.05883c49-d650-40ae-a1b3-05ad0906230a@github.com>
 <RMHHldRRmTIPahcEt8O1Cgu7LSVtmAiaV3FPfcGZ-r0=.16498238-7955-4b01-97a3-3b2f0c00acfe@github.com>
Message-ID: <7xLcXzVWOvfyjVXJaMCnkpwoE-LAwPCAtJe7fKVwdPE=.0efffb93-3feb-4c3d-9047-b3df7d08fcfb@github.com>

On Fri, 5 Jan 2024 23:55:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > 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
> > ```
> 
> Do you think these also cause the performance overhead in converting java.lang.invoke to use ClassFile API (#17108)?

Yes, I think it affects all performance critical applications.

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

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1881235421

From jpai at openjdk.org  Mon Jan  8 15:46:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Jan 2024 15:46:27 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <icMYzKHUzFqcozVLLYlNzaEeeULO1jxdVO1BszCcSdY=.26e6cc92-83aa-4eb3-85f7-9ca578a753a1@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <icMYzKHUzFqcozVLLYlNzaEeeULO1jxdVO1BszCcSdY=.26e6cc92-83aa-4eb3-85f7-9ca578a753a1@github.com>
Message-ID: <FQIQQipaxaQnaqht-h4tOcgPkVZMv4YWnMq3kuBITgo=.11f486db-a80d-48f4-acf0-f189dd09fcfe@github.com>

On Mon, 8 Jan 2024 14:47:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>  With the current proposed change, we not only rely on the Inflater for this decision but also rely on ZipEntry itself to tell us whether to read 8 bytes or 4 bytes each.

The proposed change resides solely in one single internal/private method called `readEnd(ZipEntry e)` of the `java.util.zip.ZipInputStream`. This method gets called in the internal implementation of the `ZipInputStream` when the contents of a "current" `ZipEntry` are being read and this `readEnd()` method gets passed that "current" `ZipEntry`. The passed `ZipEntry`'s `getExtra()` method is then called by the new proposed change to get hold of the byte[] representing the extra blocks of the zip entry and that byte[] is parsed to decide whether we need to read 8 bytes for compressed/uncompressed fields in the data descriptor. It's important to note that before this proposed change, this `readEnd()` method doesn't read anything out of the passed `ZipEntry` and instead only updates it, so before this change, the `ZipEntry` itself doesn't play a role in what data this `readEnd()` method processes.

The crucial part here is that the "current" `ZipEntry` is the one which was created by a previous call to `ZipInputStream.getNextEntry()` method, which is a public overridable method. Furthermore, the `ZipEntry.getExtra()` method too is overridable. So in theory, the byte[] data returned by the `ZipEntry.getExtra()` isn't controlled or validated and can be anything that the overridden method might return. So at a minimum, the newly introduced `hasZip64Extra()` private method which parses this byte[] shouldn't expect this to be parsable and thus should handle any exceptions this might generate and thus the recommendation of catching those exceptions and returning `false`.

The bigger question however is, should `readEnd()` now be entrusted the responsibility of reading the `ZipEntry.getExtra()` byte[] contents that can be anything and even if the content of the byte[] seem to represent a zip64 entry (i.e. the newly introduced `hasZip64Extra()` method returning `true`), should that decision be trusted to further lead the `readEnd()` method to read the compressed/uncompressed sizes in data descriptor as 8 bytes? Would this need additional checks of some form?

Alan and Lance have more experience in this area and I would prefer hearing their thoughts.

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

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

From asotona at openjdk.org  Mon Jan  8 15:49:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 15:49:24 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v7]
In-Reply-To: <MwVjDo_5N9V6JoE92A7cvkpLnmz4be9OASLO4bfvD8A=.1129e914-0562-4ff6-a901-33e0f4b77108@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <EaFDiubio13cGzDBRswqGpwV5AgTQ_8V-jOLSZ6u6VM=.f7001d67-2c8c-4f36-9099-3b7d00432e63@github.com>
 <MwVjDo_5N9V6JoE92A7cvkpLnmz4be9OASLO4bfvD8A=.1129e914-0562-4ff6-a901-33e0f4b77108@github.com>
Message-ID: <DF3-r7BeWDAd7FwkWSE104Nd-nOogTF_PFVyrjfLBP8=.ce01da38-52a6-46d9-8780-740aa166d262@github.com>

On Sun, 7 Jan 2024 18:24:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also `StackMapDecoder::initFrameFromLocals(ClassEntry, ...)` can benefit from 2 changes:
> 
> 1. Iterate MTD by index instead of creating copies

I'll add this fix to the performance improvements PR, thanks!

> 2. Pass ClassEntry from reader/writer constant pool to ObjectVerificationTypeInfoImpl instead of using the temporary pool

Unfortunately initi frame is implicit and the entries may not exist in the constant pool at all.

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

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1881289533

From simonis at openjdk.org  Mon Jan  8 16:02:27 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 8 Jan 2024 16:02:27 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
Message-ID: <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>

On Wed, 3 Jan 2024 21:29:57 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> 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%.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup benchmark

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1088:

> 1086:     public void putAll(Map<? extends K, ? extends V> m) {
> 1087:         if (table != null) {
> 1088:             tryPresize(m.size());

Shouldn't this be something like `tryPresize(this.size() + m.size())` to accommodate for the worst case where there are no common keys in `this` map and `m`?

Or do we intentionally try to be  conservative with memory usage? But then shouldn't we use at least `max(this.size(), m.size)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1444898430

From asotona at openjdk.org  Mon Jan  8 16:04:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 16:04:34 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v2]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <Px7u9VXjrVr5ntz7SoVAlwRYVU3tpxmYbkdncZ8sy7E=.3289f57c-b94c-434d-a830-02e44174571a@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

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

  improved StackMapDescoder::initFrameLocals performance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/bb2cf21c..c523c7be

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

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

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

From asotona at openjdk.org  Mon Jan  8 16:12:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 16:12:49 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v3]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <lqAPWtwN67zB7rJM4W0J02iMFt2OjioUsP00EYuNm8g=.69a3c239-7bd4-472b-ac80-be6004f203d4@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

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

  applied suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/c523c7be..718af508

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

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

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

From asotona at openjdk.org  Mon Jan  8 16:12:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 16:12:51 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v3]
In-Reply-To: <3zKfr4flD-Jd5ZC1zezEXPgYjF3bvVy6oUTO9D6LZgU=.2bd0d726-fb24-412a-9acb-adae4c820621@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <3zKfr4flD-Jd5ZC1zezEXPgYjF3bvVy6oUTO9D6LZgU=.2bd0d726-fb24-412a-9acb-adae4c820621@github.com>
Message-ID: <y2_FmApzB25XVD26MbOA_yzKwSNShV6gXN12ISLJOlg=.5549f360-e372-46b1-92b6-a4eced39df43@github.com>

On Mon, 8 Jan 2024 14:20:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 417:
> 
>> 415:                 bcs.bci,
>> 416:                 methodName,
>> 417:                 MethodTypeDesc.ofDescriptor(methodDesc.stringValue()).displayDescriptor()));
> 
> This seems unrelated?

methodDesc is newly an Utf8Entry, so it needs to be converted to throw with the same message

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1444917187

From asotona at openjdk.org  Mon Jan  8 16:17:47 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 16:17:47 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v4]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <YQ_0YyBhkALTLBvCxX3kfC8AALCzp0Cz3vCVErp5FwQ=.f8f4b19a-e315-40a4-9570-b13cfa1a7e80@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

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

  applied suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/718af508..bbbbbde0

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

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

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

From asotona at openjdk.org  Mon Jan  8 16:17:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 16:17:50 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v4]
In-Reply-To: <3zKfr4flD-Jd5ZC1zezEXPgYjF3bvVy6oUTO9D6LZgU=.2bd0d726-fb24-412a-9acb-adae4c820621@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <3zKfr4flD-Jd5ZC1zezEXPgYjF3bvVy6oUTO9D6LZgU=.2bd0d726-fb24-412a-9acb-adae4c820621@github.com>
Message-ID: <5UFt4rF48K6RlaiFscZDfMVKF2It_PYI4TF62Cf_Y90=.6d45eab0-7059-46f7-8c79-950ffdd86db8@github.com>

On Mon, 8 Jan 2024 14:19:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 338:
> 
>> 336:     }
>> 337: 
>> 338:     private static int countMethodStack(Utf8Entry descriptor, boolean subReturn) {
> 
> Since we use this for both locals and stack, perhaps "countMethodSlots" would be better? And maybe the "subReturn" could be a flag to switch between locals/stack

I've changes the name to the suggested "countMethodSlots" and "subReturn" to "asStackDelta" , thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1444934827

From pminborg at openjdk.org  Mon Jan  8 16:22:40 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 8 Jan 2024 16:22:40 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
Message-ID: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>

This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.

Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

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

Commit messages:
 - Add in @implSpec that segments are zeroed out

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

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

From asotona at openjdk.org  Mon Jan  8 16:37:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Jan 2024 16:37:23 GMT
Subject: RFR: 8323183: ClassFile API performance improvements
In-Reply-To: <WwYJjRNMnrCwIgK37KydJt0I_8R5TFMgBYyfy5ujMvk=.326b0626-259d-4cf4-aa50-1ce0f21ffe6a@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <WwYJjRNMnrCwIgK37KydJt0I_8R5TFMgBYyfy5ujMvk=.326b0626-259d-4cf4-aa50-1ce0f21ffe6a@github.com>
Message-ID: <Uu6lt12IKU3ujqj1WqUIGtYGc5VAkbvz735RwMGgnHI=.fe3cb806-3842-474c-bbe3-ef87caa596b1@github.com>

On Mon, 8 Jan 2024 14:43:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> You need to update the slot counting from `DirectCodeBuilder` and `StackMapDecoder` to fully avoid creating any MethodTypeDesc.

It would be good to avoid all bottlenecks, however not all of them have equal effect.
This patch avoids MTD construction for every invocation instruction. We may cache the symbol in the relevant Utf8Entry, however it still means to create each MTD at least once. "Hairy" methods doing a lot of various invocations are the most affected.

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

PR Comment: https://git.openjdk.org/jdk/pull/17306#issuecomment-1881429589

From liach at openjdk.org  Mon Jan  8 16:57:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Jan 2024 16:57:26 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v4]
In-Reply-To: <YQ_0YyBhkALTLBvCxX3kfC8AALCzp0Cz3vCVErp5FwQ=.f8f4b19a-e315-40a4-9570-b13cfa1a7e80@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <YQ_0YyBhkALTLBvCxX3kfC8AALCzp0Cz3vCVErp5FwQ=.f8f4b19a-e315-40a4-9570-b13cfa1a7e80@github.com>
Message-ID: <wEmU-Wgd2RhOXwdgvE3I099WNNrS3AQr-V9o38gZzQg=.96f6cdf6-0d7b-4fc5-8c02-32511995b605@github.com>

On Mon, 8 Jan 2024 16:17:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 356:

> 354:                 }
> 355:                 case 'L' -> {
> 356:                     while (cur < end && descriptor.charAt(cur++) != ';');

Suggestion:

                    cur = descriptor.indexOf(';', cur) + 1;
                    if (cur == 0)
                        throw new IllegalArgumentException("Bad method descriptor: " + descriptor);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1445001589

From iris at openjdk.org  Mon Jan  8 17:16:21 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 8 Jan 2024 17:16:21 GMT
Subject: RFR: 8310995: missing @since tags in 36 jdk.dynalink classes
In-Reply-To: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
References: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
Message-ID: <g4BG9dlcZBPkDxkD76wEYDHoZCyielglvVlp-Gf-E_E=.b9adc34e-674b-4d8c-ae84-2fa1ca227247@github.com>

On Mon, 8 Jan 2024 13:24:55 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding missing "@ since 9" in javadoc comment of the public classes, interfaces and packages of the jdk.dynalink module.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17305#pullrequestreview-1809643551

From mcimadamore at openjdk.org  Mon Jan  8 17:33:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 Jan 2024 17:33:22 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <C9hehLzUU0r0o6b3OOfEXkYUGsWF2L90u8l2EI0DF4M=.8d805bca-6319-46f4-9299-7e6938adbfe7@github.com>

On Mon, 8 Jan 2024 16:16:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17308#pullrequestreview-1809670119

From lancea at openjdk.org  Mon Jan  8 17:33:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 8 Jan 2024 17:33:25 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v9]
In-Reply-To: <JTGoqJSqSrp6HysaoHY1cgM-tkhE8u6v4Vt7X0toaXc=.1ab87635-f91d-41f1-88eb-610d7617bc1e@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <JTGoqJSqSrp6HysaoHY1cgM-tkhE8u6v4Vt7X0toaXc=.1ab87635-f91d-41f1-88eb-610d7617bc1e@github.com>
Message-ID: <CyONdtDxJ1TRk40khwpwzvuPhISgmyaFsAw2MMqs7bs=.44b4621c-7379-45a2-af81-e7a09439a944@github.com>

On Tue, 2 Jan 2024 13:31:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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. A new test case `noentries()` was added, resolving [JDK-8322830](https://bugs.openjdk.org/browse/JDK-8322830)
>> 
>> `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 ...
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test verifying that ZipFile can open a ZIP file with zero entries

Changes look fine.  Probably need to change the copyright from 2023 -> 2024

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17038#pullrequestreview-1787585369

From lancea at openjdk.org  Mon Jan  8 17:33:31 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 8 Jan 2024 17:33:31 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [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: <r2ZJ7mP46z_6XlodOiWsuj3KWx6xU30Qe-b93NqAZVE=.9b5e4465-d29a-4d0e-b937-809e97125836@github.com>

On Thu, 14 Dec 2023 14:55:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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. A new test case `noentries()` was added, resolving [JDK-8322830](https://bugs.openjdk.org/browse/JDK-8322830)
>> 
>> `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 ...
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge the ReadAfterClose test into ReadZip, converting it to JUnit.

test/jdk/java/util/zip/ZipFile/ReadZip.java line 233:

> 231:         URI uri = URI.create("jar:" + zip.toUri());
> 232:         Map<String, Object> env = Map.of("create", "true", "forceZIP64End", "true");
> 233:         try (FileSystem fs = FileSystems.newFileSystem(uri, env)) {

No Need to use a URI here

test/jdk/java/util/zip/ZipFile/ReadZip.java line 243:

> 241:         }
> 242:         // Read using ZipFileSystem
> 243:         try (FileSystem fs = FileSystems.newFileSystem(uri, Map.of())) {

Same comment as above regarding URI

test/jdk/java/util/zip/ZipFile/ReadZip.java line 249:

> 247: 
> 248:     /**
> 249:      * Read a zip file created via "echo hello | zip dst.zip -",

This was created using info-zip so I would clarify in the comments

test/jdk/java/util/zip/ZipFile/ReadZip.java line 257:

> 255:     @Test
> 256:     public void readZip64EndZipProcess() throws IOException, InterruptedException {
> 257:         if (Files.notExists(Paths.get("/usr/bin/zip"))) {

We should address this as the test won't run on Windows.  It would be better to store the zip as a byte array so that it can be processed on all platforms and by removing ProcessBuilder, the test run will speed up a bit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17038#discussion_r1430574058
PR Review Comment: https://git.openjdk.org/jdk/pull/17038#discussion_r1430574583
PR Review Comment: https://git.openjdk.org/jdk/pull/17038#discussion_r1430575196
PR Review Comment: https://git.openjdk.org/jdk/pull/17038#discussion_r1430578476

From lancea at openjdk.org  Mon Jan  8 17:41:21 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 8 Jan 2024 17:41:21 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits
In-Reply-To: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
Message-ID: <ZYTchNssO3D3lcRltilRrUHFp19NDcTfXk4C-GyCfuk=.380c8ae9-64e4-4e90-9701-a3581f2382d1@github.com>

On Wed, 20 Dec 2023 18:51:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> 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)

@RealCLanger, can you add this to your list to review given your efforts to add support for Posix permission support?

Eirik, I will try and make some time this week or early next for this one

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

PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1881541762

From bpb at openjdk.org  Mon Jan  8 18:22:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 8 Jan 2024 18:22:20 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int)
In-Reply-To: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
Message-ID: <O_N2zaf2wBJSQqeMxQADy6I3D-yIXGYuMB4t6Mljg2M=.5f4ecaca-2845-4f67-a090-58c4eed3abf0@github.com>

On Sat, 6 Jan 2024 18:01:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.

Do you have any benchmark results demonstrating the increased throughput?

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

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1881601270

From darcy at openjdk.org  Mon Jan  8 18:23:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 8 Jan 2024 18:23:34 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
Message-ID: <Yk28MAUo0THuTa083uu-GCAVQiUiQ5RM7N_fXwsERQ4=.d6e51491-ca9a-40fb-b7aa-a8d98d762ec8@github.com>

On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s 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

Sounds like a CSR is needed for the behavioral change proposed here.

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

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

From duke at openjdk.org  Mon Jan  8 18:32:24 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 8 Jan 2024 18:32:24 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: <gt3eJgsBL_PTs-S28nQxiWKM35-pVEgsGY8R3KPjUr8=.7e4dccf2-da0e-48d1-9393-e089c6128d3f@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).

Can anyone review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1881613425

From rriggs at openjdk.org  Mon Jan  8 19:58:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Jan 2024 19:58:34 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
Message-ID: <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>

On Mon, 8 Jan 2024 13:48:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8275338
>  - Simplified event messages.
>    Remove ckecker allocation.
>  - Corrected @Label of event and of field.
>  - Removed @module from test.
>  - 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.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8d57faa7...9ca1f36d

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 53:

> 51:     private static final Class<?>[] READ_OBJECT_NO_DATA_PARAM_TYPES = {};
> 52:     private static final Class<?>[] WRITE_REPLACE_PARAM_TYPES = {};
> 53:     private static final Class<?>[] READ_RESOLVE_PARAM_TYPES = {};

These could share a single zero length Class<?> array.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 70:

> 68:             privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
> 69:                     WRITE_REPLACE_PARAM_TYPES, Object.class);
> 70:             privilegedCheckAccessibleMethod(cl, READ_RESOLVE_NAME,

Thinking ahead to when the security manager is removed, can the code that needs private access to field values (SUID) be more narrowly accessed? Perhaps switch to using a VarHandle and MethodHandles.Lookup. This may be a longer term issue and beyond the scope of this PR.

In the naming of the `PrivilegedXXX` methods, I would drop the "privileged" part of the name.
The methods do not change the privilege level and operate correctly if when the caller has the privileges needed. And all of these methods are read-only so there is no/little risk in their implementations and avoid refitting the terminology later.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 87:

> 85:         }
> 86:         if (cl.isEnum()) {
> 87:             commitEvent(cl, SUID_NAME + " in an enum class is not effective");

Is there a best practice that can be included in the message? "SUID should not be declared"?

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:

> 111:         } else if (cl.isEnum()) {
> 112:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME +
> 113:                     " in an enum class is not effective");

Is there best practice to include in the message? "SPFN should not be declared"?

test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 33:

> 31: import org.junit.jupiter.params.provider.MethodSource;
> 32: 
> 33: import java.io.*;

Explicit imports are preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445102883
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445129715
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445107271
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445108891
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445137904

From duke at openjdk.org  Mon Jan  8 20:30:21 2024
From: duke at openjdk.org (Joshua Cao)
Date: Mon, 8 Jan 2024 20:30:21 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
 <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>
Message-ID: <AmlJOs7hkqD5rZCH-zPQzEaZOWNmg7VQS2TIJkDEbig=.be56cd27-bebe-49c2-8092-e6b98989daf0@github.com>

On Mon, 8 Jan 2024 15:59:17 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Shouldn't this be something like tryPresize(this.size() + m.size()) to accommodate for the worst case where there are no common keys in this map and m?

Its a good callout. Not sure if it is a miss, or intentionally conservative.

> But then shouldn't we use at least max(this.size(), m.size)?

We don't need to compute `max()` here. [tryPresize()](https://github.com/openjdk/jdk/blob/8a4dc79e1a40e7115e2971af81623b6b0368f41c/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2397) does that already. Although this does bring to my attention that maybe there is the same symptom of "extra unnecessary work" when merging in a smaller map. If the new size is smaller, we should just be able to exit out of `tryPresize()` without having to call the expensive `transfer()`. We would need to run a separate experiment for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1445292956

From fweimer at redhat.com  Mon Jan  8 20:31:14 2024
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 08 Jan 2024 21:31:14 +0100
Subject: The default java.library.path on Linux does not include the
 library paths in the mulitarch-spec
In-Reply-To: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
 (Glavo's message of "Sun, 24 Dec 2023 02:18:45 +0800")
References: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>
Message-ID: <878r4zh8j1.fsf@oldenburg.str.redhat.com>

* Glavo:

> 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?

Parsing /etc/ld.so.conf is the wrong approach.  Even glibc itself does
not look at that file at run time, it's strictly for ldconfig only.
(/etc/ld.so.cache is not really cache for directories that are not on
the system search path, and only listed in /etc/ld.so.conf.)  The
multi-arch patches were never upstreamed into the GNU toolchain
(although sometimes it's just a matter of automated setting the
defaults).

Apparently, Debian has decided that the multi-arch path should be
/usr/lib/?/jni (where ? gets replaced with the multi-arch directory
name).  That's probably a downstream-only patch, too.

The system paths can in theory be queried using dlinfo and
RTLD_DI_SERINFO, but I'm not sure if it will deliver the expected
results without proper multi-arch integration for the toolchain.

Thanks,
Florian


From sgibbons at openjdk.org  Mon Jan  8 20:48:39 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 8 Jan 2024 20:48:39 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v6]
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: <AvEu_RbJzfwgeNtt1nqHcyybha-iHuCXMoWXPWL3TFQ=.13823da6-b1b6-49b6-ba3f-56ef03dbc097@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 with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'openjdk:master' into indexof
 - Addressing review comments.
 - Fix for JDK-8321599
 - Support UU IndexOf
 - Only use optimization when EnableX86ECoreOpts is true
 - Fix whitespace
 - Merge branch 'openjdk:master' into indexof
 - Comments; added exhaustive-ish test
 - Subtracting 0x10 twice.
 - Stomped on r13 in switch branch calculation
 - ... and 11 more: https://git.openjdk.org/jdk/compare/8a4dc79e...600377b0

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

Changes: https://git.openjdk.org/jdk/pull/16753/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=05
  Stats: 3060 lines in 14 files changed: 2918 ins; 7 del; 135 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 vklang at openjdk.org  Mon Jan  8 21:18:41 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 8 Jan 2024 21:18:41 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC
Message-ID: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>

As per conversation in the issue.

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

Commit messages:
 - Updating copyright year for OOMEInAQS.java
 - Addresses JBS issue 8309218 but pinning OOMEInAQS to always run on G1

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

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

From attila at openjdk.org  Mon Jan  8 21:20:23 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 8 Jan 2024 21:20:23 GMT
Subject: RFR: 8310995: missing @since tags in 36 jdk.dynalink classes
In-Reply-To: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
References: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
Message-ID: <nj2NOltl5imdC_OIMZwJJflADIEJbprEJEZvb1aUJro=.94587d7b-500f-408e-8f28-ba622f868585@github.com>

On Mon, 8 Jan 2024 13:24:55 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding missing "@ since 9" in javadoc comment of the public classes, interfaces and packages of the jdk.dynalink module.

Marked as reviewed by attila (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17305#pullrequestreview-1810036469

From darcy at openjdk.org  Mon Jan  8 22:33:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 8 Jan 2024 22:33:51 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v2]
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <62atRgYaJZSgIQcN7rv32L1JC_XndbPGL3cLS9pAsq8=.f7e57e09-a67d-4232-990e-8b0e55b4f198@github.com>

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

  Add non-seal'ing support.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17239/files
  - new: https://git.openjdk.org/jdk/pull/17239/files/81084835..7222d78d

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

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

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

From darcy at openjdk.org  Mon Jan  8 22:33:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 8 Jan 2024 22:33:52 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v2]
In-Reply-To: <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
 <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
 <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>
 <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>
Message-ID: <Yjzw7MlWpdrUZctsdbNvmC9ZIh6JY7NM1vJAdVhQCtA=.b63a67f8-3dc4-4c7a-97f6-549d44d096c1@github.com>

On Wed, 3 Jan 2024 19:44:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I think the best place, or least-bad place, to discuss the "modifier" ordering of sealed/non-sealed would be an informative note on Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are not represented in the class file as access flags and thus not modeled by this class [java.lang.reflect.Modifier] .... sealed/non-sealed should be presented in the same location as final."
>> 
>> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)
>
>> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)
> 
> Naively, I thought that something like this is possible _in principle_; I might be mistaken though:
> 
> diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java
> index 851d65d06ad..014845860d0 100644
> --- a/src/java.base/share/classes/java/lang/Class.java
> +++ b/src/java.base/share/classes/java/lang/Class.java
> @@ -4771,6 +4771,30 @@ public boolean isSealed() {
>          return getPermittedSubclasses() != null;
>      }
>  
> +    private boolean isNonSealed() {
> +        if (isSealed())
> +            return false;
> +        if (!isInterface() && Modifier.isFinal(getModifiers())) {
> +            // unlike interface, class can be final
> +            return false;
> +        }
> +        // if an ancestor is sealed, this class can either be non-sealed or final
> +        return hasSealedAncestor(this);
> +    }
> +
> +    private boolean hasSealedAncestor(Class<?> clazz) {
> +        var superclass = clazz.getSuperclass();
> +        if (superclass != null) {
> +            if (superclass.isSealed() || hasSealedAncestor(superclass))
> +                return true;
> +        }
> +        for (var superinterface : clazz.getInterfaces()) {
> +            if (superinterface.isSealed() || hasSealedAncestor(superinterface))
> +                return true;
> +        }
> +        return false;
> +    }
> +
>      private native Class<?>[] getPermittedSubclasses0();
>  
>      /*

> Thanks @pavelrappo; I'll explore incorporating functionality like this into the PR, probably next week.

Pushed an initial cut of non-sealing support; will add more test cases later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1445420505

From lbourges at openjdk.org  Mon Jan  8 22:44:31 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 8 Jan 2024 22:44:31 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
Message-ID: <9BGcbHpC8oHBYuSe7X7U3nLHScUbTm86g5dXWbvLuJI=.ee24fd81-8f71-4975-a487-e40a0e60210c@github.com>

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

Keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1881936549

From mchung at openjdk.org  Tue Jan  9 00:22:51 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 00:22:51 GMT
Subject: RFR: 8322809: SystemModulesMap::classNames and moduleNames arrays do
 not match the order
Message-ID: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>

One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 

This fix is simple and write the correct class names and not to sort the values separately.

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

Commit messages:
 - minor fixes
 - 8322809: SystemModulesMap::classNames and moduleNames arrays do not match the order

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

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

From duke at openjdk.org  Tue Jan  9 04:07:31 2024
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 9 Jan 2024 04:07:31 GMT
Subject: Integrated: 8318971 : Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <Cs0RjGzUXmH7OAzG-0xH-biL0uFw0mHemfCo257vTNs=.f3ef79b5-40f3-4317-a7bd-b76337d2d320@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.

This pull request has now been integrated.

Changeset: 8ae309eb
Author:    Weibing Xiao <weibing.xiao at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ae309ebacd6947bbad2ef168ca13702e1cba099
Stats:     86 lines in 2 files changed: 84 ins; 0 del; 2 mod

8318971: Better Error Handling for Jar Tool When Processing Non-existent Files

Reviewed-by: alanb, jpai

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

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

From jpai at openjdk.org  Tue Jan  9 04:18:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Jan 2024 04:18:22 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC
In-Reply-To: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
Message-ID: <9V60NQfQ9QfVbHXA4EEqmUbO_UH9Rj4uMkRAs08oYgM=.bee69737-992c-4514-854e-c15e92375e3e@github.com>

On Mon, 8 Jan 2024 21:13:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> As per conversation in the issue.

Hello Viktor, the skara bot very helpfully has noted that this test has been problemlisted in a couple of files:

> 8309218 is used in problem lists: [test/jdk/ProblemList-zgc.txt, test/jdk/ProblemList-generational-zgc.txt]

so this current PR which is proposing to fix that test would have to remove it from those two problem lists.

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

PR Comment: https://git.openjdk.org/jdk/pull/17313#issuecomment-1882386922

From sundar at openjdk.org  Tue Jan  9 04:39:29 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 9 Jan 2024 04:39:29 GMT
Subject: Integrated: 8310995: missing @since tags in 36 jdk.dynalink classes
In-Reply-To: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
References: <39I-9UboGnOtY0f0UDxwZMwa_MuhGBK7NNEfmcJYLGw=.f4f9f3f7-e337-4d67-b2cc-695f330e142e@github.com>
Message-ID: <gs413nH4clfvHCpvxWdrouquHFvMDbMgjTTTkR6TyXU=.739afd91-2b9a-47a4-b288-b3416251475b@github.com>

On Mon, 8 Jan 2024 13:24:55 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding missing "@ since 9" in javadoc comment of the public classes, interfaces and packages of the jdk.dynalink module.

This pull request has now been integrated.

Changeset: 176606d0
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/176606d0cb9117ca9080261f898cd57339fa5a85
Stats:     38 lines in 37 files changed: 38 ins; 0 del; 0 mod

8310995: missing @since tags in 36 jdk.dynalink classes

Reviewed-by: jlaskey, iris, attila

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

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

From darcy at openjdk.org  Tue Jan  9 06:09:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 Jan 2024 06:09:36 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v3]
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <tQmBjrchA8ZkxSlAsSVoWNRq65lGRfeMPPCxKKiIB3k=.1c40757e-188a-41e8-bcd0-f3f526039108@github.com>

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

  Update non-sealed computation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17239/files
  - new: https://git.openjdk.org/jdk/pull/17239/files/7222d78d..ac897d9b

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

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

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

From jbhateja at openjdk.org  Tue Jan  9 06:16:23 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Jan 2024 06:16:23 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <cki6CtBfBxWRlqaBGdfIgfwTOBMxtt8CSefU0WVZjxI=.2752863f-2922-42cc-b3b0-63d39f29889a@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
 <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
 <1GHGK7AGinCMKjFIB5oadUP0jiZrC39Z0hncAS3H-9Y=.eb617125-1f51-4cff-889e-b15321f5c72b@github.com>
 <cki6CtBfBxWRlqaBGdfIgfwTOBMxtt8CSefU0WVZjxI=.2752863f-2922-42cc-b3b0-63d39f29889a@github.com>
Message-ID: <cDDmdwOMijr6P7CZD_5Od0skXPvJSY2Mzs8Gq_Rw7kY=.7fdf71e3-2555-4599-853b-e1afdb57d936@github.com>

On Mon, 8 Jan 2024 07:55:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> You are using `VectorMask<Integer> pred = VectorMask.fromLong(ispecies, maskctr++);`. That basically systematically iterates over all masks, which is nice for a correctness test. But that would use different density inside one test run, right? The average over the loop is still at `50%`, correct?
>>> 
>>> I was thinking more a run where the percentage over the whole loop is lower than maybe `1%`. That would get us to a point where maybe the branch prediction of non-vectorized code might be faster, what do you think?
>> 
>> An imperative loop for compression will check each mask bit to select compressible lane. Therefore mask with low or high density of set bits should show similar performance.
>
> Yes, IF it is vectorized, then there is no difference between high and low density. My concern was more if vectorization is preferrable over the scalar alternative in the low-density case, where branch prediction is more stable.

At runtime we do need to scan entire mask to pick the compressible lane corresponding to set mask bit. Thus the loop overhead of mask compare (BTW masks are held in a vector register for AVX2 targets) and jump will anyways be incurred , in addition for sparsely populated mask we may incur additional misprediction penalty for not taking if block which  extracts an element from appropriate source vector lane and insert into destination vector lane. Overall vector solution will win for most common cases for varying mask and also for very sparsely populate masks.  Here is the result of setting just a single mask bit. I am process of updating to benchmark for 128 bit species will update the patch.


    @Benchmark
    public void fuzzyFilterIntColumn() {
       int i = 0;
       int j = 0;
       long maskctr = 1;
       int endIndex = ispecies.loopBound(size);
       for (; i < endIndex; i += ispecies.length()) {
           IntVector vec = IntVector.fromArray(ispecies, intinCol, i);
           VectorMask<Integer> pred = VectorMask.fromLong(ispecies, 1);
           vec.compress(pred).intoArray(intoutCol, j);
           j += pred.trueCount();
       }
   }


Baseline:
Benchmark                                                     (size)   Mode  Cnt    Score   Error   Units
ColumnFilterBenchmark.fuzzyFilterIntColumn    1024  thrpt    2  379.059          ops/ms
ColumnFilterBenchmark.fuzzyFilterIntColumn    2047  thrpt    2  188.355          ops/ms
ColumnFilterBenchmark.fuzzyFilterIntColumn    4096  thrpt    2   95.315          ops/ms


Withopt:
Benchmark                                                     (size)   Mode  Cnt     Score   Error   Units
ColumnFilterBenchmark.fuzzyFilterIntColumn    1024  thrpt    2  7390.074          ops/ms
ColumnFilterBenchmark.fuzzyFilterIntColumn    2047  thrpt    2  3483.247          ops/ms
ColumnFilterBenchmark.fuzzyFilterIntColumn    4096  thrpt    2  1823.817          ops/ms

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1445666305

From darcy at openjdk.org  Tue Jan  9 06:20:32 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 Jan 2024 06:20:32 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v4]
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <6eO1tXOnrPVCKs0XVBKK0TWeF2aRA8Fvr64SvPthqAs=.770d1fd7-7aca-4713-aa0d-5969780042cc@github.com>

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

  Improve regression test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17239/files
  - new: https://git.openjdk.org/jdk/pull/17239/files/ac897d9b..e1efbf30

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

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

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

From alanb at openjdk.org  Tue Jan  9 07:08:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 07:08:30 GMT
Subject: Integrated: 8322829: Refactor nioBlocker to avoid blocking while
 holding Thread's interrupt lock
In-Reply-To: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
Message-ID: <CkbqKFBoPmfH4EV43NqEhJc1kmC0VsYCD7e9JB9X3UM=.68a46dc1-e4f1-49fd-b5ba-409a358343ef@github.com>

On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.

This pull request has now been integrated.

Changeset: 7286f529
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7286f5291d6aad290fda778668eeb3a7cbfd8a55
Stats:     143 lines in 6 files changed: 89 ins; 25 del; 29 mod

8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock

Reviewed-by: jpai

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

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

From eirbjo at openjdk.org  Tue Jan  9 07:29:49 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 07:29:49 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v10]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <KfbG7_NOlWac77gZ_MqSsamuKCl0zuPnmPWetPiVpjc=.74e5f69b-e218-4cb2-878a-8c733594209f@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. A new test case `noentries()` was added, resolving [JDK-8322830](https://bugs.openjdk.org/browse/JDK-8322830)
> 
> `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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Address review comments for ZIP64 End Of Central header tests
 - Copyright update for 2024

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/669b8da1..c762f4ac

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

  Stats: 30 lines in 5 files changed: 5 ins; 1 del; 24 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 eirbjo at openjdk.org  Tue Jan  9 07:29:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 07:29:50 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v9]
In-Reply-To: <CyONdtDxJ1TRk40khwpwzvuPhISgmyaFsAw2MMqs7bs=.44b4621c-7379-45a2-af81-e7a09439a944@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <JTGoqJSqSrp6HysaoHY1cgM-tkhE8u6v4Vt7X0toaXc=.1ab87635-f91d-41f1-88eb-610d7617bc1e@github.com>
 <CyONdtDxJ1TRk40khwpwzvuPhISgmyaFsAw2MMqs7bs=.44b4621c-7379-45a2-af81-e7a09439a944@github.com>
Message-ID: <q3fW130Io_sJ1k3clTcrCZsc_oJ98TXi3vX8Pe13BEQ=.d6551db0-bc8f-4885-9eb8-4ce06189d158@github.com>

On Mon, 8 Jan 2024 17:30:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Changes look fine. Probably need to change the copyright from 2023 -> 2024

No IP was produced in 2024 for most of these files, but I've updated them anyhow.

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

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1882533165

From eirbjo at openjdk.org  Tue Jan  9 07:29:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 07:29:52 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v7]
In-Reply-To: <PuEqYTbKQV88c-f6tcR3zG5RqvHJ6elwfHADf-CnnvQ=.5607e70a-8aaf-4125-97dd-2f3543760b64@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>
 <PuEqYTbKQV88c-f6tcR3zG5RqvHJ6elwfHADf-CnnvQ=.5607e70a-8aaf-4125-97dd-2f3543760b64@github.com>
Message-ID: <E67eoKZWkPPUlNNEmYgBXD-1F45meRcb0wY_PLgb-wc=.edfaa5f9-b013-4b74-99d8-57da2f212c61@github.com>

On Fri, 15 Dec 2023 11:15:30 GMT, Lance Andersen <lancea 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.
>
>> 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...

Thanks for your review, @LanceAndersen!

You might want to take a quick look at the lastest updates addressing your review before I integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1882535770

From eirbjo at openjdk.org  Tue Jan  9 07:29:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 07:29:54 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v7]
In-Reply-To: <r2ZJ7mP46z_6XlodOiWsuj3KWx6xU30Qe-b93NqAZVE=.9b5e4465-d29a-4d0e-b937-809e97125836@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <ip6qd-bohoWPTglfA3IVTBU7c46aNspVpVGAsvf_Na0=.b0ea34ea-2b18-430e-80eb-5d90df67a5b3@github.com>
 <r2ZJ7mP46z_6XlodOiWsuj3KWx6xU30Qe-b93NqAZVE=.9b5e4465-d29a-4d0e-b937-809e97125836@github.com>
Message-ID: <eWePacAQWZ26lrFp2jb32mEa9CQwb8zBpIwd2MMRrhc=.bad5ece0-515c-4eb4-825d-ec33a04a52ff@github.com>

On Mon, 18 Dec 2023 19:38:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merge the ReadAfterClose test into ReadZip, converting it to JUnit.
>
> test/jdk/java/util/zip/ZipFile/ReadZip.java line 233:
> 
>> 231:         URI uri = URI.create("jar:" + zip.toUri());
>> 232:         Map<String, Object> env = Map.of("create", "true", "forceZIP64End", "true");
>> 233:         try (FileSystem fs = FileSystems.newFileSystem(uri, env)) {
> 
> No Need to use a URI here

Fixed.

> test/jdk/java/util/zip/ZipFile/ReadZip.java line 257:
> 
>> 255:     @Test
>> 256:     public void readZip64EndZipProcess() throws IOException, InterruptedException {
>> 257:         if (Files.notExists(Paths.get("/usr/bin/zip"))) {
> 
> We should address this as the test won't run on Windows.  It would be better to store the zip as a byte array so that it can be processed on all platforms and by removing ProcessBuilder, the test run will speed up a bit

Updated comment to reference Info-ZIP. Updated the code to read the ZIP from a hex-encoded string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17038#discussion_r1445712540
PR Review Comment: https://git.openjdk.org/jdk/pull/17038#discussion_r1445713213

From jbhateja at openjdk.org  Tue Jan  9 07:42:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Jan 2024 07:42:20 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v3]
In-Reply-To: <6ipaD7eRW4J37zaeFEKVf2LUVE3C0LmZmoAeePCG2PE=.7bb8ff9a-638e-4e7f-bea2-a40a424004f0@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <tfYUCVwnSbUfHmrDgmCCefDbWdPgU7kTzSTr5J2T864=.9d5cdeff-3212-4b38-b3db-b921978a3dc1@github.com>
 <YtwzrosQJ7O7vNqkuSgzNJWnJMP3jjDY8cNvpPwdeiI=.4b1b7818-39da-4afb-944c-1a2fc8db21f7@github.com>
 <H-_wtqeXNT1YChXvdOD4-SrgThVvhS9x3VJo0Bg32-g=.cf11a935-04ee-46f2-825d-8ab2ef7325b5@github.com>
 <6ipaD7eRW4J37zaeFEKVf2LUVE3C0LmZmoAeePCG2PE=.7bb8ff9a-638e-4e7f-bea2-a40a424004f0@github.com>
Message-ID: <kWFxljJHkBiQ6Z8JQ4fVyaJoIu72MLtqEeFVOGQTOh4=.c9910d1e-3f3b-40aa-87d5-cc99c6dbf958@github.com>

On Mon, 8 Jan 2024 10:20:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> Thanks for the updates!
>>> 
>>> One more idea: Your AVX2 solution has a lot of cost for converting the mask to a permutation. Might it make sense to split this off into a separate vector-node, so that it can float out of a loop if the mask is invariant?
>> 
>> CompressV / ExpandV only accepts two inputs, vector to be operated on and mask under which operation is performed, permute table based implementation is specific to x86 backend implementation.
>
> @jatin-bhateja I think you can expand them in the matcher into several `MachNode`s that will get scheduled separately.

> Exactly, like @merykitty suggests: you can do a platform-dependent expansion.

Hi @merykitty , @eme64 , in principle platform specific lowering is a good idea where ever useful, our main concern here is to identify a loop invariant constant mask in matcher patterns and save the cost of re-loading from a permute table index. Existing loop invariant analysis moves invariant masks out of loop and GCM should be able to move expanded load from permute table out of loop. 

But this looks very restrictive and will mainly be useful for constant one hot bit mask pattern. A constant mask may have more than one set bits and in such a case we will need to generate multiple loads from permute tables and handle multiple expansion scenarios. I think we can defer that complexity for that time being.

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

PR Comment: https://git.openjdk.org/jdk/pull/17261#issuecomment-1882549544

From sspitsyn at openjdk.org  Tue Jan  9 07:49:40 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 07:49:40 GMT
Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding
 Thread's interrupt lock [v2]
In-Reply-To: <erE3oAxJqgcfoxBFdSdbdk4WkX3vsDNoYSYEE124mwA=.c451deed-ee98-43a4-a7e2-7cdb0261c8af@github.com>
References: <ssYzpMeCq05MwXgswpTrBdxplDNzEqSfQ1SU5KqDuZ0=.e0a5f96c-1058-47eb-9074-5df04b3eed84@github.com>
 <erE3oAxJqgcfoxBFdSdbdk4WkX3vsDNoYSYEE124mwA=.c451deed-ee98-43a4-a7e2-7cdb0261c8af@github.com>
Message-ID: <ZMzXvybJ2W8LyC9jPqrW4xrA_i2TTEO2oWrXqmy4o3Y=.3d3aa859-c92f-479b-9667-5563e1d460d6@github.com>

On Mon, 8 Jan 2024 09:04:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added.
>
> 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:
> 
>  - Make sun.nio.ch.Interruptible's javadoc a bit clearer
>  - Merge
>  - Merge
>  - Initial commit

I see this has been already integrated.
Just wanted to confirm that new JVMTI notifications look okay to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/17219#issuecomment-1882555612

From pminborg at openjdk.org  Tue Jan  9 08:16:33 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 9 Jan 2024 08:16:33 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
Message-ID: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>

8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

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

Commit messages:
 - Backport 7edd10e5fa71dafbbad23455553b7f5ff0a75ac9

Changes: https://git.openjdk.org/jdk22/pull/42/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=42&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321786
  Stats: 239 lines in 13 files changed: 200 ins; 21 del; 18 mod
  Patch: https://git.openjdk.org/jdk22/pull/42.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/42/head:pull/42

PR: https://git.openjdk.org/jdk22/pull/42

From asotona at openjdk.org  Tue Jan  9 08:23:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Jan 2024 08:23:49 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v5]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <oihnfk-4pSeeHmSI6zYVnzEwlGwHlOJ97DU6EEfLzxQ=.6a5e98af-2f7e-43ea-b416-ae4e0113e4d9@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

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

  Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/bbbbbde0..79394170

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

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

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

From jpai at openjdk.org  Tue Jan  9 10:11:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Jan 2024 10:11:29 GMT
Subject: RFR: 8318971: Better Error Handling for Jar Tool Processing of
 "@File" [v5]
In-Reply-To: <WayMRdjKrZODaDnOv9fozEV20NvrBoiJn47DDqf4A_Y=.0e9cabdb-0880-4f77-a8e0-a1413189a8d3@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
 <WayMRdjKrZODaDnOv9fozEV20NvrBoiJn47DDqf4A_Y=.0e9cabdb-0880-4f77-a8e0-a1413189a8d3@github.com>
Message-ID: <fGdOGSOe97h2I-e6VfUDoptTv_3Fc3YR9d0DtmsEz9E=.729cb4e8-9583-4e5e-900e-8aebc2152c0e@github.com>

On Tue, 28 Nov 2023 12:18:23 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this fix for jar tool not producing an archive if there is a missing file supplied.
>> The current behaviour will recognise missing files as an error but continue processing,
>> creating a temporary archive and then deleting it without moving to the current directory.
>> The fix is to return false when a missing file is supplied and exit immediately without continuing with any wasted processing.
>> 
>> Thanks,
>> Ryan.
>
> Ryan Wallace has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into 8318971
>  - 8318971: Better Error Handling for Jar Tool Processing of "@File"
>  - Merge branch 'master' into 8318971
>  - Merge branch 'master' into 8318971
>  - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did
>  - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did
>  - Merge branch 'master' into 8318971
>  - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did
>  - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did

This has been replaced by https://github.com/openjdk/jdk/pull/17088

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

PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1882772352

From alanb at openjdk.org  Tue Jan  9 10:12:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 10:12:25 GMT
Subject: RFR: 8322809: SystemModulesMap::classNames and moduleNames arrays
 do not match the order
In-Reply-To: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
References: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
Message-ID: <bjHhqVYQWa4-6leIvLv1s9m1qqLq0bOE2gZAfiSfwKY=.d28cb49c-66c8-4bf5-ae52-6e9b6a7d3c90@github.com>

On Tue, 9 Jan 2024 00:17:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 
> 
> This fix is simple and write the correct class names and not to sort the values separately.

Looks good, surprising we didn't notice this before now but perhaps not too common to have several modules in the run-time image with a main class. I assume you'll bump the copyright header of SystemModulesPlugin before integrating.

test/jdk/tools/jlink/plugins/SystemModuleDescriptors/ModuleMainClassTest.java line 59:

> 57:     private static final Path SRC_DIR = Paths.get(TEST_SRC, "src");
> 58:     private static final Path MODS_DIR = Paths.get("mods");
> 59:     private static final Path JMODS_DIR = Paths.get("jmods");

In passing, these can use Path.of if you want.

test/jdk/tools/jlink/plugins/SystemModuleDescriptors/src/com.foo/module-info.java line 25:

> 23: 
> 24: module com.foo {
> 25:     requires jdk.httpserver;

This `requires` means the run-time image created by the test will have 3 modules with main classes. It needs a minimum of 2 so this dependency is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17316#pullrequestreview-1810822187
PR Review Comment: https://git.openjdk.org/jdk/pull/17316#discussion_r1445883006
PR Review Comment: https://git.openjdk.org/jdk/pull/17316#discussion_r1445882416

From eirbjo at openjdk.org  Tue Jan  9 10:22:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 10:22:40 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
Message-ID: <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@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)

Eirik Bj?rsn?s has updated the pull request with a new target base 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:

 - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime.
 - Merge branch 'master' into zipfs-preserve-external-file-attrs
 - Preserve non-permission 'external file attributes' bits when setting posix permissions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17170/files
  - new: https://git.openjdk.org/jdk/pull/17170/files/7f7771ee..524159f3

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

  Stats: 3917 lines in 274 files changed: 2371 ins; 637 del; 909 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 eirbjo at openjdk.org  Tue Jan  9 10:26:23 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 10:26:23 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
Message-ID: <u_OJx8Pv_rd8Rvh9CUtD4mj1T_i10C6EILM6Rzpon0E=.d8c2955e-06f0-47fc-92f8-0fe940735bf9@github.com>

On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
>> 
>> 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)
>
> Eirik Bj?rsn?s has updated the pull request with a new target base 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:
> 
>  - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime.
>  - Merge branch 'master' into zipfs-preserve-external-file-attrs
>  - Preserve non-permission 'external file attributes' bits when setting posix permissions

Realizing that ANY read/sync operation (not just Files.setPosixPermissions)  will cause 'external file attribute' bits to be discarded, I tweaked the test added to `PosixTests` to cover such cases. The added test case calls `Files.setLastModifiedTime` and verifies that the 'external file attribute' bits are not changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1882797964

From rgiulietti at openjdk.org  Tue Jan  9 10:45:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 9 Jan 2024 10:45:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
Message-ID: <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>

On Mon, 8 Jan 2024 18:15:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8275338
>>  - Simplified event messages.
>>    Remove ckecker allocation.
>>  - Corrected @Label of event and of field.
>>  - Removed @module from test.
>>  - 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.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/966dac39...9ca1f36d
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 53:
> 
>> 51:     private static final Class<?>[] READ_OBJECT_NO_DATA_PARAM_TYPES = {};
>> 52:     private static final Class<?>[] WRITE_REPLACE_PARAM_TYPES = {};
>> 53:     private static final Class<?>[] READ_RESOLVE_PARAM_TYPES = {};
> 
> These could share a single zero length Class<?> array.

Conceptually, these are independent types. There's no logical relationship between them. Sharing a zero length array would convey a false sense of logical sharing.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 87:
> 
>> 85:         }
>> 86:         if (cl.isEnum()) {
>> 87:             commitEvent(cl, SUID_NAME + " in an enum class is not effective");
> 
> Is there a best practice that can be included in the message? "SUID should not be declared"?

Yes, that's perhaps clearer, will do.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:
> 
>> 111:         } else if (cl.isEnum()) {
>> 112:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME +
>> 113:                     " in an enum class is not effective");
> 
> Is there best practice to include in the message? "SPFN should not be declared"?

Yes, that's perhaps clearer, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445922807
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445924385
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445924424

From rgiulietti at openjdk.org  Tue Jan  9 10:50:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 9 Jan 2024 10:50:31 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
Message-ID: <cQ1yj8jICgoS6Sl7hq-s3L3wKA5ZK9dUmMldo69JbKA=.e325aa0f-75e4-4811-863d-860a85a9bb3a@github.com>

On Mon, 8 Jan 2024 18:38:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8275338
>>  - Simplified event messages.
>>    Remove ckecker allocation.
>>  - Corrected @Label of event and of field.
>>  - Removed @module from test.
>>  - 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.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/09cef802...9ca1f36d
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 70:
> 
>> 68:             privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
>> 69:                     WRITE_REPLACE_PARAM_TYPES, Object.class);
>> 70:             privilegedCheckAccessibleMethod(cl, READ_RESOLVE_NAME,
> 
> Thinking ahead to when the security manager is removed, can the code that needs private access to field values (SUID) be more narrowly accessed? Perhaps switch to using a VarHandle and MethodHandles.Lookup. This may be a longer term issue and beyond the scope of this PR.
> 
> In the naming of the `PrivilegedXXX` methods, I would drop the "privileged" part of the name.
> The methods do not change the privilege level and operate correctly if when the caller has the privileges needed. And all of these methods are read-only so there is no/little risk in their implementations and avoid refitting the terminology later.

They are called `privilegedXXX` because they _are_ (already) privileged, not because they change the privileges.

But yes, in view of removing the security manager, the implementation could be more "modern". Will have a look.

> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 33:
> 
>> 31: import org.junit.jupiter.params.provider.MethodSource;
>> 32: 
>> 33: import java.io.*;
> 
> Explicit imports are preferred.

Oops, this is the (overridable) IDE default choice

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445928358
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1445930028

From vklang at openjdk.org  Tue Jan  9 11:08:39 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Jan 2024 11:08:39 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC [v2]
In-Reply-To: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
Message-ID: <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>

> As per conversation in the issue.

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

 - Updating copyright year for zgc and zgc-gen problem lists
 - Removing OOMEInAQS from zgc and zgc-gen problem lists

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17313/files
  - new: https://git.openjdk.org/jdk/pull/17313/files/b28ae0a9..266c5c5c

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

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

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

From vklang at openjdk.org  Tue Jan  9 11:08:40 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Jan 2024 11:08:40 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC
In-Reply-To: <9V60NQfQ9QfVbHXA4EEqmUbO_UH9Rj4uMkRAs08oYgM=.bee69737-992c-4514-854e-c15e92375e3e@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
 <9V60NQfQ9QfVbHXA4EEqmUbO_UH9Rj4uMkRAs08oYgM=.bee69737-992c-4514-854e-c15e92375e3e@github.com>
Message-ID: <Qysk-wdw5hh2sZMtor1_4G0Z4mn2b05WwSb2rvrsxfY=.ab9493f9-e1d9-4a8f-b428-eeb3a3da3a96@github.com>

On Tue, 9 Jan 2024 04:15:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> As per conversation in the issue.
>
> Hello Viktor, the skara bot very helpfully has noted that this test has been problemlisted in a couple of files:
> 
>> 8309218 is used in problem lists: [test/jdk/ProblemList-zgc.txt, test/jdk/ProblemList-generational-zgc.txt]
> 
> so this current PR which is proposing to fix that test would have to remove it from those two problem lists.

@jaikiran Gah, you're obviously right, I've amended the problem lists and updated the copyright years there as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/17313#issuecomment-1882866847

From eirbjo at openjdk.org  Tue Jan  9 13:04:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 13:04:34 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <8dI73YzCb0e2jUtDGocyWiyiVqt5pz_Wwma0ELUoJNs=.f056ed16-7cb1-4a30-93d7-0ea40ca6501a@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <8dI73YzCb0e2jUtDGocyWiyiVqt5pz_Wwma0ELUoJNs=.f056ed16-7cb1-4a30-93d7-0ea40ca6501a@github.com>
Message-ID: <bFhYcILKE68DNTCcT6STDPggz7LUrxsLPbDDhR22yrY=.43dec878-6eb1-43ab-80ac-d33b357c2f97@github.com>

On Mon, 8 Jan 2024 14:59:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 692:
> 
>> 690:     private static boolean isZip64ExtBlockSizeValid(int blockSize) {
>> 691:         // Uncompressed and compressed size fields are 8 bytes each
>> 692:         return blockSize == 16;
> 
> I'm not following this check. As far as I can see, the `blockSize` being passed to this method is the size of the zip64 extra entry and as per the spec:
> 
> 
> 4.5.3 -Zip64 Extended Information Extra Field (0x0001):
> 
>       The following is the layout of the zip64 extended 
>       information "extra" block. 
> 
>       ....
> 
>         Value      Size       Description
>         -----      ----       -----------
> (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
>         Size       2 bytes    Size of this "extra" block
>         Original 
>         Size       8 bytes    Original uncompressed file size
>         Compressed
>         Size       8 bytes    Size of compressed data
>         Relative Header
>         Offset     8 bytes    Offset of local header record
>         Disk Start
>         Number     4 bytes    Number of the disk on which
>                               this file starts 
> 
> So shouldn't it be 8 + 8 + 8 + 4 = 28 bytes and not 16 bytes? Did I misunderstand the code or the spec?

The size of the "Zip64 Extended Information Extra Field" is determined by the following factors:

- Whether the corresponding field in the LOC or CEN record is larger than the "magic" limit (0xFFFF for "Disk Start Number", 0xFFFFFFFF for "Original Size", "Compressed Size" and "Relative Header Offset"). A component should only appear if the corresponding LOC record field is set to 0xFFFF or 0xFFFFFFFF).
- Whether the Zip64 extra field is contained in a LOC or a CEN header: While Zip64 fields in both headers may have the "Original Size" and "Compressed Size" fields, only the CEN has the corresponding "Relative Header Offset" and "Disk Start Number" fields. So these two components are not relevant in the LOC. (And indeed they are not present in the Info-ZIP test vector used in this PR. See `Zip64DataDescriptor` for the structure)

In this case, we have a Zip64 extra header in a LOC record using "data descriptors". While the spec mandates that LOC headers with the "data descriptor" bit set must have their "size" and "compressed size" fields set to zero, in this case we also have Zip64, so these fields are actually set to 0xFFFFFFFF, and zero is the value used in the Zip64 extra fields. (This means the data size will in this case will always be 16. And we could also add another check verifying that both components are zero as expected when used with a "data descriptor") 

The full text of 4.5.3:


4.5.3 -Zip64 Extended Information Extra Field (0x0001):

      The following is the layout of the zip64 extended 
      information "extra" block. If one of the size or
      offset fields in the Local or Central directory
      record is too small to hold the required data,
      a Zip64 extended information record is created.
      The order of the fields in the zip64 extended 
      information record is fixed, but the fields MUST
      only appear if the corresponding Local or Central
      directory record field is set to 0xFFFF or 0xFFFFFFFF.
``` 

It would probably be better to compute the expected size of the Zip64 data by looking at the "size" and "compressed size" in the LOC and add 8 bytes for each field being 0xFFFFFFFF. Then the expected size (8 or 16) can be compared to the actual size. 

I think some recent validation of the Zip64 extra fields in the CEN header was implemented this way. Unfortunately, these values are actually ignored by `readLOC` when it determines the "data descriptor" bit being set, so they are not available to `readEND`.

Perhaps it would be better if we moved the testing for presence of a valid Zip64 extra field into `readLOC` method and have that method set some boolean flag to indicate to readEND whether it should expect 4 or 8 byte fields in the data descriptor? 

This would allow us to check for "size" and "compressed size" being  0xFFFFFFFF AND it would alleviate concerns about trustig the ZipEntry.getExtra value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1446064783

From eirbjo at openjdk.org  Tue Jan  9 13:06:56 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 13:06:56 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v10]
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: <R7qjZwqzM0CD8WJ3FlF3Oe2fkcWmqIWWohMsVBfg7Wo=.957a5ff4-99f3-4009-80ac-2d689cd1b47d@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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Move hasZip64Extra(e) to the end of the 4/8-byte data descriptor check
 - hasZip64 does not throw IOException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/ddff130f..900c5b19

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

  Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 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 asotona at openjdk.org  Tue Jan  9 13:30:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Jan 2024 13:30:58 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v6]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <vv6b9UyJVc1a4LutL5B8ymMNGjsRlW0yd5GSwSQfgRs=.cdee9633-619d-4ea0-a5e3-f390e6a9d30a@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

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

 - updated copyright year
 - reverted custom method slots counting in StackCounter
 - improved and extended GenerateStackMaps benchmarks and renamed to CodeAttributeTools

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/79394170..5f67f8c1

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

  Stats: 313 lines in 3 files changed: 132 ins; 171 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17306/head:pull/17306

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

From asotona at openjdk.org  Tue Jan  9 13:41:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Jan 2024 13:41:27 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v6]
In-Reply-To: <vv6b9UyJVc1a4LutL5B8ymMNGjsRlW0yd5GSwSQfgRs=.cdee9633-619d-4ea0-a5e3-f390e6a9d30a@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <vv6b9UyJVc1a4LutL5B8ymMNGjsRlW0yd5GSwSQfgRs=.cdee9633-619d-4ea0-a5e3-f390e6a9d30a@github.com>
Message-ID: <HCIPzA2efA6UEnYlkYxigS36KJN2wBPxjdxil0vptHI=.879f1d36-bab8-415b-83c4-20f955c19af6@github.com>

On Tue, 9 Jan 2024 13:30:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - updated copyright year
>  - reverted custom method slots counting in StackCounter
>  - improved and extended GenerateStackMaps benchmarks and renamed to CodeAttributeTools

StackMapGenerator benchmark is heavily benefiting from symbols caching for repeated execution.
I've created new CodeAttributeTools::benchmarkStackMapsGenerator and CodeAttributeTools::benchmarkStackCounter with focus on single use of each parsed model to eliminate background caching effect.
Then I've compared version with custom method parameter slots counting and version with symbols cached in NaT entries.
There is insignificant difference between these two approaches.
Explanation may by that repeated uses of the same NaT entry (of the called method) compensate the initial parsing cost. 

Based on these results I've decided to revert custom parameter slots counting method and apply the previously proposed solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/17306#issuecomment-1883065817

From epeter at openjdk.org  Tue Jan  9 14:16:25 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 9 Jan 2024 14:16:25 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v4]
In-Reply-To: <Vn-zGBfezGTxMFXWYVJIIzVHpKC_cVx6pGb2OkvngAY=.2edd5815-c807-4af8-9b3f-4bffaba6b26c@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <Vn-zGBfezGTxMFXWYVJIIzVHpKC_cVx6pGb2OkvngAY=.2edd5815-c807-4af8-9b3f-4bffaba6b26c@github.com>
Message-ID: <wyAOpKCfgLb4qdVul3EFci1E0oMXYJQdpkCgDu9RG3g=.8f1e6d87-78b3-4989-9fe8-dda75dfb1758@github.com>

On Mon, 8 Jan 2024 06:23:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

I think we are almost there! ?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5291:

> 5289:   if (bt == T_INT || bt == T_FLOAT) {
> 5290:     vmovmskps(rtmp, mask, vec_enc);
> 5291:     shlq(rtmp, 5);

Suggestion:

    shlq(rtmp, 5); // for 32 bit rows (8 int)

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5309:

> 5307:     assert(bt == T_LONG || bt == T_DOUBLE, "");
> 5308:     vmovmskpd(rtmp, mask, vec_enc);
> 5309:     shlq(rtmp, 5);

Suggestion:

    shlq(rtmp, 5); // for 32 bit rows (4 long)

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1018:

> 1016:   } else {
> 1017:     assert(esize == 64, "");
> 1018:     // Loop to generate 16 x 4 int expand permute index table. A row is accessed

Suggestion:

    // Loop to generate 16 x 4 long expand permute index table. A row is accessed

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1811224600
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1446133371
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1446133800
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1446132575

From epeter at openjdk.org  Tue Jan  9 14:16:27 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 9 Jan 2024 14:16:27 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v2]
In-Reply-To: <cDDmdwOMijr6P7CZD_5Od0skXPvJSY2Mzs8Gq_Rw7kY=.7fdf71e3-2555-4599-853b-e1afdb57d936@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <WxUU9x5ESUGDgCgwovsdsbpQuOcX_z2maL5HTz5zcsg=.7a648d56-57b8-449c-b7d1-8f862ffe7924@github.com>
 <ibL3OEA6ISjRFozrRZWh4519G_SYNbitZeyFGzLKTCQ=.2cda098f-4e0d-4392-b13b-353142e31bf6@github.com>
 <PwDqe-LRTnKCCx-q_I1rXJlQx50f-LutjYVs05JCqXo=.41001210-83ae-455d-945a-a4e8dffc8a71@github.com>
 <gMyOKool-l6bFsyrBrCOGJf_M-lIVte8zrfsEU9dKuE=.c9a05312-196c-44c2-9ac4-0c069d85a360@github.com>
 <1GHGK7AGinCMKjFIB5oadUP0jiZrC39Z0hncAS3H-9Y=.eb617125-1f51-4cff-889e-b15321f5c72b@github.com>
 <cki6CtBfBxWRlqaBGdfIgfwTOBMxtt8CSefU0WVZjxI=.2752863f-2922-42cc-b3b0-63d39f29889a@github.com>
 <cDDmdwOMijr6P7CZD_5Od0skXPvJSY2Mzs8Gq_Rw7kY=.7fdf71e3-2555-4599-853b-e1afdb57d936@github.com>
Message-ID: <MIo0WdGY9H6dAyJHYPzWGIkc7_N2lHMhvc6b23J0bLE=.26db8340-437e-46e4-b1dd-a8a9d9e6bab0@github.com>

On Tue, 9 Jan 2024 06:13:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes, IF it is vectorized, then there is no difference between high and low density. My concern was more if vectorization is preferrable over the scalar alternative in the low-density case, where branch prediction is more stable.
>
> At runtime we do need to scan entire mask to pick the compressible lane corresponding to set mask bit. Thus the loop overhead of mask compare (BTW masks are held in a vector register for AVX2 targets) and jump will anyways be incurred , in addition for sparsely populated mask we may incur additional misprediction penalty for not taking if block which  extracts an element from appropriate source vector lane and insert into destination vector lane. Overall vector solution will win for most common cases for varying mask and also for very sparsely populate masks.  Here is the result of setting just a single mask bit. 
> 
> 
>     @Benchmark
>     public void fuzzyFilterIntColumn() {
>        int i = 0;
>        int j = 0;
>        long maskctr = 1;
>        int endIndex = ispecies.loopBound(size);
>        for (; i < endIndex; i += ispecies.length()) {
>            IntVector vec = IntVector.fromArray(ispecies, intinCol, i);
>            VectorMask<Integer> pred = VectorMask.fromLong(ispecies, 1);
>            vec.compress(pred).intoArray(intoutCol, j);
>            j += pred.trueCount();
>        }
>    }
> 
> 
> Baseline:
> Benchmark                                                     (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.fuzzyFilterIntColumn    1024  thrpt    2  379.059          ops/ms
> ColumnFilterBenchmark.fuzzyFilterIntColumn    2047  thrpt    2  188.355          ops/ms
> ColumnFilterBenchmark.fuzzyFilterIntColumn    4096  thrpt    2   95.315          ops/ms
> 
> 
> Withopt:
> Benchmark                                                     (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.fuzzyFilterIntColumn    1024  thrpt    2  7390.074          ops/ms
> ColumnFilterBenchmark.fuzzyFilterIntColumn    2047  thrpt    2  3483.247          ops/ms
> ColumnFilterBenchmark.fuzzyFilterIntColumn    4096  thrpt    2  1823.817          ops/ms

Nice, thanks for the data!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1446138902

From alanb at openjdk.org  Tue Jan  9 14:45:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 14:45:23 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
Message-ID: <clvyYnKC07n_T_Jp6bm5YTDNNr2BFjYtPuo03M9ZLLE=.1b08f606-a169-4fd2-8622-0c2ad8bb18e2@github.com>

On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
>> 
>> 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)
>
> Eirik Bj?rsn?s has updated the pull request with a new target base 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:
> 
>  - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime.
>  - Merge branch 'master' into zipfs-preserve-external-file-attrs
>  - Preserve non-permission 'external file attributes' bits when setting posix permissions

I looked at the update to ZipFileSystem and the changes look right. I don't have time right now to look at the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1883176230

From epeter at openjdk.org  Tue Jan  9 15:20:33 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 9 Jan 2024 15:20:33 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v6]
In-Reply-To: <AvEu_RbJzfwgeNtt1nqHcyybha-iHuCXMoWXPWL3TFQ=.13823da6-b1b6-49b6-ba3f-56ef03dbc097@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <AvEu_RbJzfwgeNtt1nqHcyybha-iHuCXMoWXPWL3TFQ=.13823da6-b1b6-49b6-ba3f-56ef03dbc097@github.com>
Message-ID: <U3PQa9RYF_exiJ9GDtbpfr5olJR1p9NUdWq35jLYUYk=.ece7a995-c3b7-4eeb-b72f-8e078fa69706@github.com>

On Mon, 8 Jan 2024 20:48:39 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 with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - Stomped on r13 in switch branch calculation
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/8a4dc79e...600377b0

@asgibbons I cannot yet promise to review this, I just left a few comments after scrolling through this change. I'm especially scared of reviewing `src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp`.

I launched testing for Commit 21 / v05.

Maybe an ignorant question: How would avx512 be affected?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 83:

> 81: 
> 82: //   const __m256i first = _mm256_set1_epi8(needle[0]);
> 83: //   const __m256i last = _mm256_set1_epi8(needle[k - 1]);

I think it would be nicer if you had comment `//` on every line, and no gaps.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1608:

> 1606:     //   vector compares when size is 2 * VEC_SIZE or less. 38    8. Use 4
> 1607:     //   vector compares when size is 4 * VEC_SIZE or less. 39    9. Use 8
> 1608:     //   vector compares when size is 8 * VEC_SIZE or less.  */

Is this formatting intended?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1672:

> 1670: 
> 1671:     // 98              VPCMPEQ VEC_SIZE(%rdi), %ymm2, %ymm2
> 1672:     // 99              vpmovmskb %ymm2, %eax

It seems that here the comments and code is strangely interleaved / shifted. What is this all for?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 2301:

> 2299:     // 388             setg    %dl
> 2300:     // 389             leal    -1(%rdx, %rdx), %eax
> 2301:     __ movzbl(rcx, Address(rsi, rax, Address::times_1, -0x20));

Down here it is even worse

test/jdk/java/lang/StringBuffer/IndexOf.java line 34:

> 32: public class IndexOf {
> 33: 
> 34:   static Random generator = new Random(1999);

Would it be an alternative to use the this:

import jdk.test.lib.Utils;
...
Random random = Utils.getRandomInstance();

This has a random seed, but it is always printed in the output and can be set via a test-flag.

test/jdk/java/lang/StringBuffer/IndexOf.java line 44:

> 42:     }
> 43:     System.out.println("");
> 44:     generator.setSeed(1999);

Is there a good reason for a fixed seed?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-1811353722
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1446211178
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1446210544
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1446216019
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1446217305
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1446221928
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1446223038

From prappo at openjdk.org  Tue Jan  9 15:32:23 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 9 Jan 2024 15:32:23 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v4]
In-Reply-To: <Yjzw7MlWpdrUZctsdbNvmC9ZIh6JY7NM1vJAdVhQCtA=.b63a67f8-3dc4-4c7a-97f6-549d44d096c1@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <_ite9QgHcs358rEjJAhgTHyUVk1TRh-4Ww5z8z0jIZk=.d00ab53f-4114-43b4-8b52-62c65b665a82@github.com>
 <jZEa1lrFOFjDQxJXlz9x4WdOBRUOezQmibNF7RuSgnA=.f2ee7c15-0eed-48f4-babd-e7b42f26c13c@github.com>
 <r3OBDsPrt_QhhKD2XyGoyhpsYMOHomON9tKvAGEnqNA=.0c176692-7eb6-41e8-906c-e685cc418869@github.com>
 <EoZ2OcXfmkdNi3amLKAoggTaMrCTjqFFa0wPZB980y0=.1a858fbe-4d04-427f-872c-ac6f300cf9bd@github.com>
 <Yjzw7MlWpdrUZctsdbNvmC9ZIh6JY7NM1vJAdVhQCtA=.b63a67f8-3dc4-4c7a-97f6-549d44d096c1@github.com>
Message-ID: <h2k0l1ayvVunXRkSOY0uTYAgI5hBO-cHff9iQyRS1yM=.08a30d57-8f20-4dfd-bc87-9a307e825c96@github.com>

On Mon, 8 Jan 2024 22:29:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> Since it doesn't seem possible to do so, I did not attempt to relay "non-sealed" information in this PR :-)
>> 
>> Naively, I thought that something like this is possible _in principle_; I might be mistaken though:
>> 
>> diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java
>> index 851d65d06ad..014845860d0 100644
>> --- a/src/java.base/share/classes/java/lang/Class.java
>> +++ b/src/java.base/share/classes/java/lang/Class.java
>> @@ -4771,6 +4771,30 @@ public boolean isSealed() {
>>          return getPermittedSubclasses() != null;
>>      }
>>  
>> +    private boolean isNonSealed() {
>> +        if (isSealed())
>> +            return false;
>> +        if (!isInterface() && Modifier.isFinal(getModifiers())) {
>> +            // unlike interface, class can be final
>> +            return false;
>> +        }
>> +        // if an ancestor is sealed, this class can either be non-sealed or final
>> +        return hasSealedAncestor(this);
>> +    }
>> +
>> +    private boolean hasSealedAncestor(Class<?> clazz) {
>> +        var superclass = clazz.getSuperclass();
>> +        if (superclass != null) {
>> +            if (superclass.isSealed() || hasSealedAncestor(superclass))
>> +                return true;
>> +        }
>> +        for (var superinterface : clazz.getInterfaces()) {
>> +            if (superinterface.isSealed() || hasSealedAncestor(superinterface))
>> +                return true;
>> +        }
>> +        return false;
>> +    }
>> +
>>      private native Class<?>[] getPermittedSubclasses0();
>>  
>>      /*
>
>> Thanks @pavelrappo; I'll explore incorporating functionality like this into the PR, probably next week.
> 
> Pushed an initial cut of non-sealing support; will add more test cases later.

Thanks for including `non-sealed`, Joe.

Regarding your implementation: you are right that only the direct superclass and direct superinterfaces need to be explored for being `sealed`. No need to explore the full ancestry. So, recursion in my [initial proposal] was superfluous.

That said, I have a question on [JLS 8.1.1.2], which you copied as inline commentary:

> It is a compile-time error if a class is declared non-sealed but has neither a sealed direct superclass nor a sealed direct superinterface.
>
> Thus, a subclass of a non-sealed class cannot itself be declared non-sealed.

I wonder if it can be clarified to account for hierarchies where a `non-sealed` class or `non-sealed` interface has a `non-sealed` direct superinterface, or a `non-sealed` class has a `non-sealed` direct superclass.

For example:

    sealed interface A permits B { }

    sealed interface I permits X { }

    non-sealed interface B extends A { }

    non-sealed interface X extends B, I { }

and

    sealed class A permits B { }

    sealed interface I permits C { }

    non-sealed class B extends A { }

    non-sealed class C extends B implements I { }

(CC'ing @GavinBierman)

[initial proposal]: https://github.com/openjdk/jdk/pull/17239#discussion_r1440867004
[JLS 8.1.1.2]: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1.2

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1446243516

From jbhateja at openjdk.org  Tue Jan  9 15:35:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Jan 2024 15:35:29 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v5]
In-Reply-To: <jjgXujKNdw7Bt5KopUrv05_onDaqVqRU1auhh5kNqbA=.a9218000-d912-4395-85fd-59d67128d40d@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jjgXujKNdw7Bt5KopUrv05_onDaqVqRU1auhh5kNqbA=.a9218000-d912-4395-85fd-59d67128d40d@github.com>
Message-ID: <iYTxZYOoyZwslkBPlDmrHtWt17M3Br0YYJswEcooeqw=.ad03b10a-0cb4-4e58-a26e-4d2ff56729f6@github.com>

On Thu, 21 Dec 2023 15:21:08 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:
> 
>   Addressing review comments.

src/hotspot/share/opto/library_call.cpp line 1202:

> 1200: 
> 1201:   Node* result = nullptr;
> 1202:   bool do_intrinsic =

Name change suggestion: do_intrinsic -> call_opt_stub

src/hotspot/share/opto/library_call.cpp line 1224:

> 1222:     result = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
> 1223:   } else {
> 1224:     result = make_indexOf_node(src_start, src_count, tgt_start, tgt_count,

Existing routines emits IR to handle following special cases
1) tgt_cnt > src_cnt return -1
2) tgt_cnt == 0 return 0.
Should we not be preserving those check  before calling stub ?

src/hotspot/share/opto/library_call.cpp line 1273:

> 1271:   Node* result = nullptr;
> 1272: 
> 1273:   if ((StubRoutines::string_indexof() != nullptr) && (ae == StrIntrinsicNode::LL)) {

Why are we not calling stub for StrIntrinsicNode::UU

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1444390460
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1444406814
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1444420392

From jvernee at openjdk.org  Tue Jan  9 15:45:50 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 9 Jan 2024 15:45:50 GMT
Subject: RFR: 8322324: java/foreign/TestStubAllocFailure.java times out while
 waiting for forked process
Message-ID: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>

The issue with this test, and the test of JDK-8322324, seems to be that the forked processes write to stderr/stdout, without this output being read before the process terminates. The buffer might fill up if the output is not being read, which means that the process will stall when writing (see stack trace in JBS issue).

`OutputAnalyzer` has ways to prevent this by continuously reading from the output streams in separate threads, but because the current code calls `Process::waitFor` before creating the `OutputAnalyzer`, we never actually read the written output of the fork, which occasionally results in a stall and subsequent timeout.

The fix proposed by this patch is to use `ProcessTools::startProcess`, instead of `ProcessBuilder::start`, which will also start the necessary reader threads, preventing a stall. Incidentally, `startProcess` also has built-in timeout handling which we can use.

Testing:
-  500 runs of both java/foreign/TestStubAllocFailure.java and java/foreign/critical/TestCriticalUpcall on various Windows x64 hosts (100 iterations was enough to observe the failure twice).
-  `jdk_foreign` suite.

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

Commit messages:
 - use ProcessTools.startProcess to avoid stderr getting stuck

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

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

From eirbjo at openjdk.org  Tue Jan  9 15:58:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 15:58:50 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <GwoKrY4yXDACm2cyzqpGvUFe-Ph-TpEtT1fqauSSC40=.9bfc81e0-2f88-4833-aa59-e43b8da6ebc5@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <GwoKrY4yXDACm2cyzqpGvUFe-Ph-TpEtT1fqauSSC40=.9bfc81e0-2f88-4833-aa59-e43b8da6ebc5@github.com>
Message-ID: <4DBEyAm9wq9wlZYHoRXAN5OQHQc2JoAR-HF52TR_3xs=.446be42a-502f-4754-ae74-6b73ed8931ad@github.com>

On Mon, 8 Jan 2024 15:04:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 654:
> 
>> 652:      * data contained no Zip64 field.
>> 653:      */
>> 654:     private boolean hasZip64Extra(ZipEntry e) throws IOException {
> 
> Given what this method does, I think it shouldn't throw an IOException (or any other exception for that matter), should strictly return true or false. I haven't imported this code locally, but as far as I can see in its implementation, there doesn't seem to be anything that throws a checked IOException, so perhaps this throws is already redundant?

Fixed.

> The private `hasMagic` method in `java.util.jar.JarOutputStream` has an example where we catch the `ArrayIndexOutOfBoundsException` when dealing with the extra data, we should do similar here and return `false`.

I've updated for loop to verify that there is always at least 4 bytes available to read the two short fields, so now a `ArrayIndexOutOfBoundsException` should no longer be possible. I also extended the test in the PR to cover a case where the LOC extra field  ends with a truncated extra field (just the two-byte tag) to cover this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1446275924
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1446278827

From rgiulietti at openjdk.org  Tue Jan  9 16:05:30 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 9 Jan 2024 16:05:30 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v10]
In-Reply-To: <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
Message-ID: <uykTLI6Tdxl4dU2bAxwgdqmAWI59Wik-o_kQigvFWO0=.b6a08dd6-e773-4b36-8c0b-53664d98646f@github.com>

On Tue, 2 Jan 2024 14:37:27 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - 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
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/adcabea9...252b7378

src/java.base/share/classes/java/math/BigInteger.java line 3998:

> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
> 3997:         if (i != -1)
> 3998:             return ((m1[i] & LONG_MASK) < (m2[i] & LONG_MASK)) ? -1 : 1;

As suggested earlier, you could make us of `Integer.compareUnsigned`, which is an intrinsic not involving `long`s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1446287937

From eirbjo at openjdk.org  Tue Jan  9 16:11:29 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 16:11:29 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <FQIQQipaxaQnaqht-h4tOcgPkVZMv4YWnMq3kuBITgo=.11f486db-a80d-48f4-acf0-f189dd09fcfe@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <icMYzKHUzFqcozVLLYlNzaEeeULO1jxdVO1BszCcSdY=.26e6cc92-83aa-4eb3-85f7-9ca578a753a1@github.com>
 <FQIQQipaxaQnaqht-h4tOcgPkVZMv4YWnMq3kuBITgo=.11f486db-a80d-48f4-acf0-f189dd09fcfe@github.com>
Message-ID: <kylq7vnFMahj1JGr5C1Qc3X3-R7e33aANhNe5evZy6g=.aab6ace1-28aa-4167-9206-ac99e3cab21b@github.com>

On Mon, 8 Jan 2024 15:43:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The crucial part here is that the "current" `ZipEntry` is the one which was created by a previous call to `ZipInputStream.getNextEntry()` method, which is a public overridable method. Furthermore, the `ZipEntry.getExtra()` method too is overridable. So in theory, the byte[] data returned by the `ZipEntry.getExtra()` isn't controlled or validated and can be anything that the overridden method might return. 

Yes, we cannot rely on the extra field contents to be well-formed and valid. Because of this, `hasZip64Extra` must be coded in a defensive fashion, meaning it returns true only when it finds a valid Zip64 extra field, false otherwise. It should also never throw exceptions. This is the case regardless of ZipEntry concerns, since the input ZIP data may already be malformed.

> The bigger question however is, should `readEnd()` now be entrusted the responsibility of reading the `ZipEntry.getExtra()` byte[] contents that can be anything and even if the content of the byte[] seem to represent a zip64 entry (i.e. the newly introduced `hasZip64Extra()` method returning `true`), should that decision be trusted to further lead the `readEnd()` method to read the compressed/uncompressed sizes in data descriptor as 8 bytes? Would this need additional checks of some form?

To avoid readEND relying on "untrusted" ZipEntry contents, I moved the call to `hasZip64Extra` from `readEND` to `readLOC`. This allows `hasZip64Extra` to work on the raw extra data.

 For this to work, I needed to add a new internal boolean field `ZipInputStream.expectEightBitDataDescriptor`. When true, this flag indicates to `readEND` that the next data descriptor has 8-byte size fields.

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

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

From jbhateja at openjdk.org  Tue Jan  9 16:48:56 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Jan 2024 16:48:56 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

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

  Using emulated variable blend E-Core optimized instruction.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/257a6351..c3f1c50e

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

  Stats: 28 lines in 4 files changed: 18 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17261/head:pull/17261

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

From rriggs at openjdk.org  Tue Jan  9 17:09:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 17:09:33 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v10]
In-Reply-To: <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <VpNkRJpyBMooj7o6n4OYC8w50Hm0g88GVfFOzwAMULI=.84ef08f0-f901-4c1a-9839-d4fcfc477de0@github.com>
Message-ID: <xruV0TY5jhnLxqv9f_yhQYx8xbSN4sltlE6WvIOOGVs=.2d62efc4-a9ec-42a8-97f0-96a6bef1e938@github.com>

On Tue, 2 Jan 2024 14:37:27 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - 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
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/c09491be...252b7378

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14630#pullrequestreview-1811620453

From mcimadamore at openjdk.org  Tue Jan  9 17:10:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Jan 2024 17:10:30 GMT
Subject: RFR: 8322324: java/foreign/TestStubAllocFailure.java times out
 while waiting for forked process
In-Reply-To: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>
References: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>
Message-ID: <1_l0mm7ASoP9Zrd83W7NAmVut1EgqVTdldFOmHJBagU=.99ba2717-475e-432c-ad62-83eb5e0abdca@github.com>

On Tue, 9 Jan 2024 14:18:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The issue with this test, and the test of JDK-8322324, seems to be that the forked processes write to stderr/stdout, without this output being read before the process terminates. The buffer might fill up if the output is not being read, which means that the process will stall when writing (see stack trace in JBS issue).
> 
> `OutputAnalyzer` has ways to prevent this by continuously reading from the output streams in separate threads, but because the current code calls `Process::waitFor` before creating the `OutputAnalyzer`, we never actually read the written output of the fork, which occasionally results in a stall and subsequent timeout.
> 
> The fix proposed by this patch is to use `ProcessTools::startProcess`, instead of `ProcessBuilder::start`, which will also start the necessary reader threads, preventing a stall. Incidentally, `startProcess` also has built-in timeout handling which we can use.
> 
> Testing:
> -  500 runs of both java/foreign/TestStubAllocFailure.java and java/foreign/critical/TestCriticalUpcall on various Windows x64 hosts (100 iterations was enough to observe the failure twice).
> -  `jdk_foreign` suite.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17324#pullrequestreview-1811623046

From eirbjo at openjdk.org  Tue Jan  9 17:11:29 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 9 Jan 2024 17:11:29 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v10]
In-Reply-To: <R7qjZwqzM0CD8WJ3FlF3Oe2fkcWmqIWWohMsVBfg7Wo=.957a5ff4-99f3-4009-80ac-2d689cd1b47d@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <R7qjZwqzM0CD8WJ3FlF3Oe2fkcWmqIWWohMsVBfg7Wo=.957a5ff4-99f3-4009-80ac-2d689cd1b47d@github.com>
Message-ID: <bdoC-r2YRSCmVvH4HSWuOT7o7PArCtJ4IpFN_ECuBXw=.3872e9bc-073b-46e8-916f-f98ad5243e5b@github.com>

On Tue, 9 Jan 2024 13:06:56 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move hasZip64Extra(e) to the end of the 4/8-byte data descriptor check
>  - hasZip64 does not throw IOException

Putting this PR in draft mode while I figure out how to address review comments.

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

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

From mchung at openjdk.org  Tue Jan  9 17:12:29 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 17:12:29 GMT
Subject: RFR: 8322809: SystemModulesMap::classNames and moduleNames arrays
 do not match the order
In-Reply-To: <bjHhqVYQWa4-6leIvLv1s9m1qqLq0bOE2gZAfiSfwKY=.d28cb49c-66c8-4bf5-ae52-6e9b6a7d3c90@github.com>
References: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
 <bjHhqVYQWa4-6leIvLv1s9m1qqLq0bOE2gZAfiSfwKY=.d28cb49c-66c8-4bf5-ae52-6e9b6a7d3c90@github.com>
Message-ID: <tnrkMa0Z4_VcK5fBu2Cu_WXMTO_k2oPvRVEApQP5yAY=.074f8cd5-9624-4b3d-9f6a-0c2d3d98fa2c@github.com>

On Tue, 9 Jan 2024 10:06:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 
>> 
>> This fix is simple and write the correct class names and not to sort the values separately.
>
> test/jdk/tools/jlink/plugins/SystemModuleDescriptors/src/com.foo/module-info.java line 25:
> 
>> 23: 
>> 24: module com.foo {
>> 25:     requires jdk.httpserver;
> 
> This `requires` means the run-time image created by the test will have 3 modules with main classes. It needs a minimum of 2 so this dependency is okay.

Yes and `net.foo` requires `jdk.jfr` which also has a main class.  The run-time image created by this test has 4 modules.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17316#discussion_r1446377152

From mcimadamore at openjdk.org  Tue Jan  9 17:14:27 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Jan 2024 17:14:27 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout, 
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario
In-Reply-To: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
Message-ID: <QGvbnTJ2vVVsFax-i-jxCR_EDPYPuMBKjGJ4g3pG7R8=.ea6ca818-5d6b-4d69-bb77-11b1eb304b26@github.com>

On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> 8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1944:

> 1942:      *         in the provided layout
> 1943:      * @throws IndexOutOfBoundsException if {@code offset > byteSize() - layout.byteSize()}
> 1944:      *         or {@code offset < 0}

Why is UOE being removed here (and elsewhere) ?

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

PR Review Comment: https://git.openjdk.org/jdk22/pull/42#discussion_r1446379983

From naoto at openjdk.org  Tue Jan  9 17:17:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 17:17:27 GMT
Subject: [jdk22] RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
References: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
Message-ID: <zWIt8iQrg6ZU2HYwQ1LExy7WnhQ90YSZ4J-e1K2oXvo=.ff1d8475-56d0-4691-8ca5-ef0c2eda170a@github.com>

On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

LGTM. Thanks for the backport.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/35#pullrequestreview-1811635378

From iris at openjdk.org  Tue Jan  9 17:39:22 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 17:39:22 GMT
Subject: [jdk22] RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
References: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
Message-ID: <xLpz0NnPU2zXvtF8ZtRd4KVFnXgeYgYTbR8_UkLaWuU=.1fcd7915-1c51-4dc2-b312-adb1fd0eb93a@github.com>

On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/35#pullrequestreview-1811674978

From dlutker at openjdk.org  Tue Jan  9 17:56:24 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 9 Jan 2024 17:56:24 GMT
Subject: [jdk22] Integrated: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
References: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
Message-ID: <FUQZ9fsukHUswq12Zx7WVvHweBiExIfjzPbk1nOOtDM=.1f84667f-4152-4b88-b012-deb663cfe34b@github.com>

On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

This pull request has now been integrated.

Changeset: acc4829e
Author:    Dan Lutker <dlutker at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/acc4829ec39b3a7dacd3e2a872ba3becd89b175e
Stats:     140 lines in 14 files changed: 94 ins; 15 del; 31 mod

8322725: (tz) Update Timezone Data to 2023d

Reviewed-by: naoto, iris
Backport-of: 2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc

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

PR: https://git.openjdk.org/jdk22/pull/35

From mchung at openjdk.org  Tue Jan  9 18:05:15 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 18:05:15 GMT
Subject: RFR: 8322809: SystemModulesMap::classNames and moduleNames arrays
 do not match the order [v2]
In-Reply-To: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
References: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
Message-ID: <2tsmVf-5nwoCCapsKvCYDD7jn0FA_I40i0269VEOjbw=.03e2f1ec-8b34-403a-b521-179a9962f0e1@github.com>

> One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 
> 
> This fix is simple and write the correct class names and not to sort the values separately.

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

  Update the test verification to check the expected modules with main class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17316/files
  - new: https://git.openjdk.org/jdk/pull/17316/files/0e5350a5..d0e55ddb

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

  Stats: 33 lines in 4 files changed: 25 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17316.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17316/head:pull/17316

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

From mchung at openjdk.org  Tue Jan  9 18:13:43 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 18:13:43 GMT
Subject: RFR: 8322809: SystemModulesMap::classNames and moduleNames arrays
 do not match the order [v3]
In-Reply-To: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
References: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
Message-ID: <GfULSZU0ojIcNXpq03L6n1Y-k74YqYZtXK4CQbmgmA8=.008870d3-1b12-4a0e-912e-7509fb4808c5@github.com>

> One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 
> 
> This fix is simple and write the correct class names and not to sort the values separately.

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

  review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17316/files
  - new: https://git.openjdk.org/jdk/pull/17316/files/d0e55ddb..c6e98d55

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

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

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

From duke at openjdk.org  Tue Jan  9 18:19:58 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 9 Jan 2024 18:19:58 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v2]
In-Reply-To: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
Message-ID: <gbkNqd_9VopHgS5nCa-krV3WKYwh5K5AcSHcLzbn0wc=.27f37a1c-b23c-49d7-8f1e-7b8b50cfd0e9@github.com>

> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.

fabioromano1 has updated the pull request with a new target base 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 'patch-BigIntegerDivision' of https://github.com/fabioromano1/jdk into patch-BigIntegerDivision
 - Merge branch 'openjdk:master' into patch-BigIntegerDivision
 - Merge branch 'openjdk:master' into patch-BigIntegerDivision
 - Added file to estimate divWord running time
 - Implementation of divWord(long, int) changed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17291/files
  - new: https://git.openjdk.org/jdk/pull/17291/files/5345d6d8..2d432f8d

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

  Stats: 11455 lines in 120 files changed: 9221 ins; 991 del; 1243 mod
  Patch: https://git.openjdk.org/jdk/pull/17291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17291/head:pull/17291

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

From alanb at openjdk.org  Tue Jan  9 18:23:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 18:23:22 GMT
Subject: RFR: 8322809: SystemModulesMap::classNames and moduleNames arrays
 do not match the order [v3]
In-Reply-To: <GfULSZU0ojIcNXpq03L6n1Y-k74YqYZtXK4CQbmgmA8=.008870d3-1b12-4a0e-912e-7509fb4808c5@github.com>
References: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
 <GfULSZU0ojIcNXpq03L6n1Y-k74YqYZtXK4CQbmgmA8=.008870d3-1b12-4a0e-912e-7509fb4808c5@github.com>
Message-ID: <hj1KUlGHR5r-3ELzFzX7JrnfbCwfdks1DTHk7wpMQzQ=.08206c13-4e29-47bd-beac-e28b64a84e73@github.com>

On Tue, 9 Jan 2024 18:13:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 
>> 
>> This fix is simple and write the correct class names and not to sort the values separately.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17316#pullrequestreview-1811743456

From duke at openjdk.org  Tue Jan  9 18:24:49 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 9 Jan 2024 18:24:49 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
Message-ID: <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>

> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.

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

  Removed trailing whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17291/files
  - new: https://git.openjdk.org/jdk/pull/17291/files/2d432f8d..2460b066

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

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

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

From naoto at openjdk.org  Tue Jan  9 18:26:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 18:26:30 GMT
Subject: RFR: 8320788: The system properties page is missing some properties
Message-ID: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>

Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has alos been drafted.

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

Depends on: https://git.openjdk.org/jdk/pull/17065

Commit messages:
 - initial commit

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

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

From dfuchs at openjdk.org  Tue Jan  9 18:35:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Jan 2024 18:35:26 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
Message-ID: <HECLeGNZfOMdoMkYhCtvkfLLvyX2CbR9jRMASwL23fE=.3780d393-9077-4be4-9c02-f9f78a254be0@github.com>

On Tue, 9 Jan 2024 10:42:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 87:
>> 
>>> 85:         }
>>> 86:         if (cl.isEnum()) {
>>> 87:             commitEvent(cl, SUID_NAME + " in an enum class is not effective");
>> 
>> Is there a best practice that can be included in the message? "SUID should not be declared"?
>
> Yes, that's perhaps clearer, will do.

Typically in other places in the JDK we use `priviledgedXxx` for naming methods that are simple wrappers that call `xxx` from within a `doPrivileged`. The method is called privileged because it doesn't require the caller to use `doPrivileged`.

That is something like:


String privilegedGetProperty(String property) {
     return AccessController.doPrivileged((...) () -> System.getProperty(property));
} 


See for instance: https://github.com/openjdk/jdk/blob/ee98d262181f5822609674c71c85ad4576ac1632/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L107

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1446460008

From duke at openjdk.org  Tue Jan  9 19:01:22 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 9 Jan 2024 19:01:22 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int)
In-Reply-To: <O_N2zaf2wBJSQqeMxQADy6I3D-yIXGYuMB4t6Mljg2M=.5f4ecaca-2845-4f67-a090-58c4eed3abf0@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <O_N2zaf2wBJSQqeMxQADy6I3D-yIXGYuMB4t6Mljg2M=.5f4ecaca-2845-4f67-a090-58c4eed3abf0@github.com>
Message-ID: <RyqHF-DkH8DyFR5rrCuqyGa5yhe0eXjsPpe9pK_yGT4=.5af4e288-ba79-496d-911d-34652271e645@github.com>

On Mon, 8 Jan 2024 18:20:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Do you have any benchmark results demonstrating the increased throughput?

I just uploaded a class for random tests. But during the execution, I've found a non banal problem concerning the old implementation's running time.
The problem is this: the running time of the old implementation depends strongly by the difference between the initial approximation and the exact value of the quotient. So, I tried to construct of a possible worst case, attempting to maximizing this distance. To do so, I maximized the dividend `n = -2` (treated as unsigned) and minimized the divisor `d = 3`. The result is this:
The computed initial approximation is `q0 = (n >>> 1) / (d >>> 1)`, so `q0 == 9223372036854775807L`, while the exact quotient is `q = 6148914691236517204L`. This implies that the number of iterations is  `|q - q0| == 3074457345618258603L` in the worst case. This means that the running time of the old implementation can be EXPONENTIAL in the bit length of |q - q0|.
Experimentally, you can notice this by the fact that if you try to do an increasingly number of divisions, the running time quickly becomes unreasonably long, this happens just over the `2^18 == 262144` divisions.

Anyway, these are my results of the tests' running.

New algorithm:

Time to do 1 divisions: PT0.002411989S
Average time for division: PT0.002411989S

Time to do 2 divisions: PT0.000003997S
Average time for division: PT0.000001998S

Time to do 4 divisions: PT0.000006194S
Average time for division: PT0.000001548S

Time to do 8 divisions: PT0.000013294S
Average time for division: PT0.000001661S

Time to do 16 divisions: PT0.000021008S
Average time for division: PT0.000001313S

Time to do 32 divisions: PT0.000042878S
Average time for division: PT0.000001339S

Time to do 64 divisions: PT0.000131778S
Average time for division: PT0.000002059S

Time to do 128 divisions: PT0.000163048S
Average time for division: PT0.000001273S

Time to do 256 divisions: PT0.000383142S
Average time for division: PT0.000001496S

Time to do 512 divisions: PT0.000319871S
Average time for division: PT0.000000624S

Time to do 1024 divisions: PT0.000413291S
Average time for division: PT0.000000403S

Time to do 2048 divisions: PT0.000591616S
Average time for division: PT0.000000288S

Time to do 4096 divisions: PT0.00135185S
Average time for division: PT0.00000033S

Time to do 8192 divisions: PT0.013735457S
Average time for division: PT0.000001676S

Time to do 16384 divisions: PT0.008213712S
Average time for division: PT0.000000501S

Time to do 32768 divisions: PT0.020442676S
Average time for division: PT0.000000623S

Time to do 65536 divisions: PT0.011344406S
Average time for division: PT0.000000173S

Time to do 131072 divisions: PT0.018728826S
Average time for division: PT0.000000142S

Time to do 262144 divisions: PT0.043171006S
Average time for division: PT0.000000164S

Time to do 524288 divisions: PT0.073636145S
Average time for division: PT0.00000014S

Time to do 1048576 divisions: PT0.120018251S
Average time for division: PT0.000000114S

Time to do 2097152 divisions: PT0.157581276S
Average time for division: PT0.000000075S

Time to do 4194304 divisions: PT0.348321185S
Average time for division: PT0.000000083S

Time to do 8388608 divisions: PT0.642987771S
Average time for division: PT0.000000076S

Time to do 16777216 divisions: PT1.104336979S
Average time for division: PT0.000000065S

Time to do 33554432 divisions: PT2.229299703S
Average time for division: PT0.000000066S

Time to do 67108864 divisions: PT4.386180114S
Average time for division: PT0.000000065S

Time to do 134217728 divisions: PT8.833464454S
Average time for division: PT0.000000065S

Time to do 268435456 divisions: PT17.504803158S
Average time for division: PT0.000000065S

Old algorithm:
Time to do 1 divisions: PT0.00590102S
Average time for division: PT0.00590102S

Time to do 2 divisions: PT0.000002469S
Average time for division: PT0.000001234S

Time to do 4 divisions: PT0.000014707S
Average time for division: PT0.000003676S

Time to do 8 divisions: PT0.00000855S
Average time for division: PT0.000001068S

Time to do 16 divisions: PT0.000027515S
Average time for division: PT0.000001719S

Time to do 32 divisions: PT0.000073262S
Average time for division: PT0.000002289S

Time to do 64 divisions: PT0.000340843S
Average time for division: PT0.000005325S

Time to do 128 divisions: PT0.00016714S
Average time for division: PT0.000001305S

Time to do 256 divisions: PT0.001197161S
Average time for division: PT0.000004676S

Time to do 512 divisions: PT0.000273558S
Average time for division: PT0.000000534S

Time to do 1024 divisions: PT0.000617932S
Average time for division: PT0.000000603S

Time to do 2048 divisions: PT0.000892402S
Average time for division: PT0.000000435S

Time to do 4096 divisions: PT0.001367862S
Average time for division: PT0.000000333S

Time to do 8192 divisions: PT1.319736346S
Average time for division: PT0.0001611S

Time to do 16384 divisions: PT8.109278716S
Average time for division: PT0.000494951S

Time to do 32768 divisions: PT0.038191561S
Average time for division: PT0.000001165S

Time to do 65536 divisions: PT3.249995508S
Average time for division: PT0.00004959S

Time to do 131072 divisions: PT0.203684211S
Average time for division: PT0.000001553S

Time to do 262144 divisions: PT9.767934912S
Average time for division: PT0.000037261S

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

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1883610685

From mchung at openjdk.org  Tue Jan  9 19:02:25 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 19:02:25 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v10]
In-Reply-To: <fEOSmdpqGvSjhneA4HwwnUDRazCfKk-URTfHrU5kWEo=.4748c0b6-e25c-4d41-ae94-d6b93f20acbd@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <fEOSmdpqGvSjhneA4HwwnUDRazCfKk-URTfHrU5kWEo=.4748c0b6-e25c-4d41-ae94-d6b93f20acbd@github.com>
Message-ID: <1Irw5mD_A5ganCLYI4kcZgg1tI5_nZI22VdrYZ0_szI=.7d7bf120-21c3-4cc1-b21e-72097f7ae18b@github.com>

On Mon, 8 Jan 2024 15:28:50 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:
> 
>   initialization of template entries by index

The change looks fine.   Please rerun the benchmark after JDK-8323183 is integrated.   I made JDK-8294961 blocked by JDK-8323183 to ensure it goes in after it.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 144:

> 142:         //static template ClassModel holds pre-defined constant pool entries
> 143:         //proxy transformed from the template shares the template constant pool
> 144:         //each direct use of the template pool entry is significantly faster

Suggestion:

        // static template ClassModel holds pre-defined constant pool entries
        // proxy transformed from the template shares the template constant pool
        // each direct use of the template pool entry is significantly faster

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17121#pullrequestreview-1811800119
PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1446484346

From iris at openjdk.org  Tue Jan  9 19:05:24 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 19:05:24 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <ghuDMQmj_CqvIIbcuhvDJyBQf4foVBTEiLkddfSZORU=.1e976ca6-7644-410a-9b44-0174fc0a8cca@github.com>

On Tue, 9 Jan 2024 00:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.

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

> 816:      * {@link #getProperty(String)} operation.
> 817:      * <p>
> 818:      * In addition to the above set of system properties, locale related

I think I'd consider a slight reduction in the first/last phrases leaving this equivalent statement:

Additional locale-related system properties defined by the {@link Locale##default_locale Default Locale} section in the {@code Locale} class description may also be obtained with this method.

(Note that I couldn't find the referenced Locale section, but perhaps I was looking at an older version of the spec.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446489646

From naoto at openjdk.org  Tue Jan  9 19:23:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 19:23:53 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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/17317/files
  - new: https://git.openjdk.org/jdk/pull/17317/files/19128cc8..b1d31163

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

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

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

From naoto at openjdk.org  Tue Jan  9 19:28:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 19:28:25 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <ghuDMQmj_CqvIIbcuhvDJyBQf4foVBTEiLkddfSZORU=.1e976ca6-7644-410a-9b44-0174fc0a8cca@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <ghuDMQmj_CqvIIbcuhvDJyBQf4foVBTEiLkddfSZORU=.1e976ca6-7644-410a-9b44-0174fc0a8cca@github.com>
Message-ID: <sFNooffpbu7SRfyuENb2XcqJpbExD0KTdlHNf-eu8t0=.d10e8370-5a9a-4fb6-ac60-18ee30c53238@github.com>

On Tue, 9 Jan 2024 19:02: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:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 818:
> 
>> 816:      * {@link #getProperty(String)} operation.
>> 817:      * <p>
>> 818:      * In addition to the above set of system properties, locale related
> 
> I think I'd consider a slight reduction in the first/last phrases leaving this equivalent statement:
> 
> Additional locale-related system properties defined by the {@link Locale##default_locale Default Locale} section in the {@code Locale} class description may also be obtained with this method.
> 
> (Note that I couldn't find the referenced Locale section, but perhaps I was looking at an older version of the spec.)

That's concise and clearer. Replaced the wording. As to the referenced Locale section, it is in the PR (#17065) which this PR is dependent on and is not yet integrated. Sorry for the confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446509254

From darcy at openjdk.org  Tue Jan  9 19:37:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 Jan 2024 19:37:54 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v5]
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <7O4qJUxX7-h3MJvXd-m2h2DaVTfsGhJ0r7D0GSaYMrQ=.5d0eac8b-7b9c-4322-9fba-b0409d8307fe@github.com>

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

  Update spec; test sealed class structures.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17239/files
  - new: https://git.openjdk.org/jdk/pull/17239/files/e1efbf30..2d02d9b1

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

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

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

From jlu at openjdk.org  Tue Jan  9 19:38:42 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jan 2024 19:38:42 GMT
Subject: [jdk22] RFR: 8321480: ISO 4217 Amendment 176 Update
Message-ID: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>

Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

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

Commit messages:
 - Backport 8b24851b9d3619c41c7a6cdb9193ed26a9b732dc

Changes: https://git.openjdk.org/jdk22/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=45&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321480
  Stats: 43 lines in 5 files changed: 10 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk22/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk22/pull/45

From naoto at openjdk.org  Tue Jan  9 19:44:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 19:44:26 GMT
Subject: [jdk22] RFR: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
References: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
Message-ID: <h3nkY91F6Dk0MqEEmKYcEChACde8bVDXBD6mIyPWdl8=.ba2c97d0-3498-49f8-8ee2-74ed0bea7c23@github.com>

On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/45#pullrequestreview-1811865198

From iris at openjdk.org  Tue Jan  9 20:01:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 20:01:23 GMT
Subject: [jdk22] RFR: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
References: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
Message-ID: <8CTfAXZVKWBPS8F4Q4g0zl-WfR1cAd4duwdhvvfo1Zc=.5d007b8e-ef02-4eb5-9ee8-e4347e4ca352@github.com>

On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Confirmed changes identical to those in main-line.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/45#pullrequestreview-1811892304

From rriggs at openjdk.org  Tue Jan  9 20:05:25 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 20:05:25 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v5]
In-Reply-To: <7O4qJUxX7-h3MJvXd-m2h2DaVTfsGhJ0r7D0GSaYMrQ=.5d0eac8b-7b9c-4322-9fba-b0409d8307fe@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <7O4qJUxX7-h3MJvXd-m2h2DaVTfsGhJ0r7D0GSaYMrQ=.5d0eac8b-7b9c-4322-9fba-b0409d8307fe@github.com>
Message-ID: <ezZLh0yFXc-O2mlKX8ijXp6H-ZQavbQx8PPGVBXXQUY=.26fa4733-d813-4917-a8b4-f6429674d13a@github.com>

On Tue, 9 Jan 2024 19:37:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
>> 
>> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec; test sealed class structures.

The updates to add non-sealed look fine.
The CSR needs an update to the Solution section to mention non-sealed.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17239#pullrequestreview-1811897603

From iris at openjdk.org  Tue Jan  9 20:05:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 20:05:23 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <-IvORgI8rz7JVl4RnKgDp-xIwHFr90hzLKQfs6hV2oU=.c16e40b3-cd82-4657-9d43-9ce0e128558c@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Looks good.  Associated CSR also Reviewed.

Thanks for the clarification regarding the pending new section in Locale.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811895882

From joehw at openjdk.org  Tue Jan  9 20:05:25 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 9 Jan 2024 20:05:25 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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/lang/System.java line 819:

> 817:      * <p>
> 818:      * Additional locale-related system properties defined by the
> 819:      * {@link Locale##default_locale Default Locale} section in the {@code Locale}

Is that "##" a typo? double pound signs usually leads to the top of the page. I see PR 17065 also had "##" for links to default_locale.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446542159

From rriggs at openjdk.org  Tue Jan  9 20:09:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 20:09:22 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <09sqOazp5DWhr4hCA5xzAiaFVRjToA83nb95B6fTG5A=.e74b7353-2213-4877-801b-39f6580b7847@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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).

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

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811902084

From rriggs at openjdk.org  Tue Jan  9 20:09:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 20:09:24 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
 <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>
Message-ID: <HVm_ZDxLjm3PezqqpAQ2sI4sRKQUGgTGRGdPJzW2Tfg=.ea5d196f-9996-4e27-beef-f6f6acfbdfb1@github.com>

On Tue, 9 Jan 2024 20:01:28 GMT, Joe Wang <joehw 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/lang/System.java line 819:
> 
>> 817:      * <p>
>> 818:      * Additional locale-related system properties defined by the
>> 819:      * {@link Locale##default_locale Default Locale} section in the {@code Locale}
> 
> Is that "##" a typo? double pound signs usually leads to the top of the page. I see PR 17065 also had "##" for links to default_locale.

The "##" refers to a normal html tag or id in the target page.  A single "#" refers to a javadoc defined method or field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446545971

From bpb at openjdk.org  Tue Jan  9 20:36:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Jan 2024 20:36:23 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <XkodRePcgpHJyuMbSsGYskOBIeFIozxCc-gaw-rNuC4=.8ea825da-ec44-4d09-b05d-4d609b9fcc90@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811961077

From joehw at openjdk.org  Tue Jan  9 20:52:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 9 Jan 2024 20:52:23 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <q8GpaWt2ojkAa07QPojAww7t-sKmAx-SQpejCKFctFM=.38f4510e-4073-4f8a-b51d-d3089fd5e6f1@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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 joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811984674

From duke at openjdk.org  Tue Jan  9 21:12:48 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 9 Jan 2024 21:12:48 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v3]
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <2xlUrhw42cy8_UcZNgKYy5WMm0kupZaztNScq8TJe9w=.4c7421f7-f6be-471b-8cb9-5ced9023de65@github.com>

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

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

 - reverted zipfs changes and made adjustements for ZipInputStream comments
 - Merge branch 'master' into zip-doc-changes
 - Fixed more line breaks
 - fixed line breaks
 - document patch for JDK-8319122

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16424/files
  - new: https://git.openjdk.org/jdk/pull/16424/files/919666a0..dbecd485

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

  Stats: 831197 lines in 4897 files changed: 202043 ins; 545027 del; 84127 mod
  Patch: https://git.openjdk.org/jdk/pull/16424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16424/head:pull/16424

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

From duke at openjdk.org  Tue Jan  9 21:12:50 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 9 Jan 2024 21:12:50 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <DXJR3I2x9PeojuQ3QYQE-pZguDRQlCrg_eLvQaJIJwA=.a3ae7ebc-47c5-4e73-9dd6-6b07448b0832@github.com>
 <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com>
Message-ID: <biV5cpLE900w7Hw70FAFlG82CLTQ2PiiDsAGbp-rhuM=.3ab7e567-c3bb-4137-8f94-d61ee8bece7d@github.com>

On Wed, 22 Nov 2023 22:23:18 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 77:
>> 
>>> 75:  *
>>> 76:  * Whenever possible, {@linkplain ZipFile} should be used for parsing ZIP
>>> 77:  * archives since it correctly reads data from the central directory.
>> 
>> I think it's okay to extend the existing API note to say that the stream may contain ZIP file entries that are not are not named in the central directory.  I think I would replace the sentence "Additionally ..." with "Consequently, a ZipInputStream that reads from a ZIP file may read ZIP file entries that are not in the ZIP file's central directory". 
>> 
>> The sentence "This class might also fail to properly parse ZIP archives that have prepended data" will confuse readers as it hints of unreliability in scenarios and begs too many questions on where the data is prepended. So I think drop this unless you can come up with something better.
>> 
>> Replacing the sentence "ZipFile may be used ..." is okay but I don't think the proposed text works. The API note starts with text to say that a ZipInputStream doesn't read the CEN so saying "correctly reads from the central directory" is very confusing. ZipInputStream is a JDK 1.1 era API, it is what it is and would be disruptive to deprecate.
>
> Thank you, I will work on this

I updated the file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1446615096

From duke at openjdk.org  Tue Jan  9 21:12:51 2024
From: duke at openjdk.org (Yakov Shafranovich)
Date: Tue, 9 Jan 2024 21:12:51 GMT
Subject: RFR: JDK-8319122: Improve documentation of various Zip-file
 related APIs [v2]
In-Reply-To: <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
 <MB-hP--bprxUE_APW7PgqovwYbRVJAkVqRTekG4_w60=.010bb2ba-8b35-4f9c-b002-b761d7264880@github.com>
 <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com>
 <xRCA93VnAm2A587CHpU0tndPVAccgRHcSFeA_7XUmYg=.b4742d67-73f1-4cc3-91dd-48bbfbbbb64c@github.com>
 <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com>
Message-ID: <EBglJjKFK34CLUeT7ZTdrcME0LV7hQpH-ChXmN_JZ9M=.71598f29-84c9-42ee-bb18-17783cae7067@github.com>

On Mon, 13 Nov 2023 18:11:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking?
>
>> That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking?
> 
> Yes, I think it should be separated, and it would be nice to drop the changes to jdk.zipfs from this PR. If/when this documentation is written then it describe the "/" character and the synthesized links that are "." and "..", which can lead to documentation that a zip file with name elements of  "." or ".." cannot be opened as a file system.

Removed from this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1446615201

From darcy at openjdk.org  Tue Jan  9 21:59:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 Jan 2024 21:59:46 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v6]
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <K8z9dX4iHwz3Wldus9cF-faAgRtpYcsJ45fQLkix2pQ=.bc7fafe5-d913-419a-bc6e-385fde08fd26@github.com>

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

  Expand test cases.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17239/files
  - new: https://git.openjdk.org/jdk/pull/17239/files/2d02d9b1..d5a451d0

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

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

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

From mchung at openjdk.org  Tue Jan  9 22:07:34 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 22:07:34 GMT
Subject: Integrated: 8322809: SystemModulesMap::classNames and moduleNames
 arrays do not match the order
In-Reply-To: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
References: <4TWPkaJd1708eKFaH4VgfSqe8VXaeUMnx2jsSOj_EnQ=.2cf2e702-83aa-410c-bdef-f571bbac5cbf@github.com>
Message-ID: <L4J1pe99EbPOcgO6hVAnBMhaZ2buCCSMqQgnZs26ykk=.d57ea7fc-da4e-4400-b9f1-2af842d20219@github.com>

On Tue, 9 Jan 2024 00:17:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> One optimization of Jlink SystemModulesPlugin pre-resolves the module graph for modules with a main class.  It stores the name of the initial module and the generated `SystemModules` class name in two arrays that can be obtained from `SystemModulesMap::moduleNames` and `SystemModulesMap::classNames`.   The elements in the array returned by `classNames()` are supposed to correspond to the elements in the array returned by `moduleNames()`.    However, the implementation sorts both arrays by the value of the elements. 
> 
> This fix is simple and write the correct class names and not to sort the values separately.

This pull request has now been integrated.

Changeset: f3be138e
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3be138eb80c9e7f6cc21afb75cda9e49b667c8a
Stats:     290 lines in 6 files changed: 282 ins; 0 del; 8 mod

8322809: SystemModulesMap::classNames and moduleNames arrays do not match the order

Reviewed-by: alanb

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

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

From clanger at openjdk.org  Tue Jan  9 22:11:24 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 9 Jan 2024 22:11:24 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
Message-ID: <cphfaaS6jhDe7bY_9DE5I_d0YK-qzg6nMcRODJe-h5E=.81a65a8b-fec8-4d94-a39d-c706392516fb@github.com>

On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
>> 
>> 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)
>
> Eirik Bj?rsn?s has updated the pull request with a new target base 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:
> 
>  - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime.
>  - Merge branch 'master' into zipfs-preserve-external-file-attrs
>  - Preserve non-permission 'external file attributes' bits when setting posix permissions

Looks correct to me, too. I also went over the changes to the test and it makes sense.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17170#pullrequestreview-1812103908

From mchung at openjdk.org  Tue Jan  9 22:23:53 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 Jan 2024 22:23:53 GMT
Subject: [jdk22] RFR: 8322809: SystemModulesMap::classNames and moduleNames
 arrays do not match the order
Message-ID: <A8bIBR9I_FngBg7MUvF5w16niv6i-OzTNflY0S2uZD0=.fa0668fd-6ec5-4600-b502-cf700ad10d8f@github.com>

This pull request contains a backport of commit [f3be138e](https://github.com/openjdk/jdk/commit/f3be138eb80c9e7f6cc21afb75cda9e49b667c8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mandy Chung on 9 Jan 2024 and was reviewed by Alan Bateman.

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

Commit messages:
 - Backport f3be138eb80c9e7f6cc21afb75cda9e49b667c8a

Changes: https://git.openjdk.org/jdk22/pull/46/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=46&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322809
  Stats: 290 lines in 6 files changed: 282 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk22/pull/46.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/46/head:pull/46

PR: https://git.openjdk.org/jdk22/pull/46

From jlu at openjdk.org  Tue Jan  9 22:58:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jan 2024 22:58:26 GMT
Subject: [jdk22] Integrated: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
References: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
Message-ID: <Q5kK4z9sXmm9qpdwFFNqD5itXP0b5OWUniZqu3fBYcw=.3e6d1559-a7a3-4090-810d-f32e5bd10c42@github.com>

On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This pull request has now been integrated.

Changeset: a8df5597
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a8df5597638c4cbcbc9a56bad7034b9af5efc32d
Stats:     43 lines in 5 files changed: 10 ins; 0 del; 33 mod

8321480: ISO 4217 Amendment 176 Update

Reviewed-by: naoto, iris
Backport-of: 8b24851b9d3619c41c7a6cdb9193ed26a9b732dc

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

PR: https://git.openjdk.org/jdk22/pull/45

From naoto at openjdk.org  Tue Jan  9 23:14:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 23:14:34 GMT
Subject: Integrated: 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: <7ejuSu-wzpLFmEEQjlvunZTqizCIPB6TrdZi0B1jejs=.8ed135cb-34e7-45a6-abca-ec0000b1dc5e@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.

This pull request has now been integrated.

Changeset: 376051a9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/376051a9be95e0e4acf3c59d0eba3e9ef8727d79
Stats:     81 lines in 1 file changed: 71 ins; 0 del; 10 mod

8320919: Clarify Locale related system properties

Reviewed-by: smarks, rriggs

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

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

From sspitsyn at openjdk.org  Tue Jan  9 23:29:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 23:29:22 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <cWJUikQsPhbJ98Oa25FYcTkizSxUhLXMTMChsrNm5BE=.5452e37b-2db7-4bcf-9ba0-9dd12d4f4959@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 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!

Ping! Need, at list, one review for this 22 backport, please.

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

PR Comment: https://git.openjdk.org/jdk22/pull/23#issuecomment-1883954123

From naoto at openjdk.org  Tue Jan  9 23:31:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 23:31:23 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v2]
In-Reply-To: <HVm_ZDxLjm3PezqqpAQ2sI4sRKQUGgTGRGdPJzW2Tfg=.ea5d196f-9996-4e27-beef-f6f6acfbdfb1@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
 <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>
 <HVm_ZDxLjm3PezqqpAQ2sI4sRKQUGgTGRGdPJzW2Tfg=.ea5d196f-9996-4e27-beef-f6f6acfbdfb1@github.com>
Message-ID: <OfNGqjNz1Lb9iTBCgPgC1SWsyLX34NrODWr4nHYS1fE=.e5ab3520-223f-4b8b-869d-ff3ac5fe705d@github.com>

On Tue, 9 Jan 2024 20:06:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 819:
>> 
>>> 817:      * <p>
>>> 818:      * Additional locale-related system properties defined by the
>>> 819:      * {@link Locale##default_locale Default Locale} section in the {@code Locale}
>> 
>> Is that "##" a typo? double pound signs usually leads to the top of the page. I see PR 17065 also had "##" for links to default_locale.
>
> The "##" refers to a normal html tag or id in the target page.  A single "#" refers to a javadoc defined method or field.

Thanks, Joe. As Roger mentioned, the `##` can be used for user-defined anchors since JDK20 ( https://bugs.openjdk.org/browse/JDK-8294195)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446723242

From naoto at openjdk.org  Tue Jan  9 23:40:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 23:40:35 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v3]
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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 18 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8320788-system.getProperties
 - Reflects review comments
 - initial commit
 - 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>
 - ... and 8 more: https://git.openjdk.org/jdk/compare/376051a9...7444bb51

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

Changes: https://git.openjdk.org/jdk/pull/17317/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17317&range=02
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17317/head:pull/17317

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

From naoto at openjdk.org  Wed Jan 10 00:03:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 00:03:41 GMT
Subject: [jdk22] RFR: 8320919: Clarify Locale related system properties
Message-ID: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>

Backporting the document clarification to JDK22

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

Commit messages:
 - Backport 376051a9be95e0e4acf3c59d0eba3e9ef8727d79

Changes: https://git.openjdk.org/jdk22/pull/47/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=47&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/jdk22/pull/47.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/47/head:pull/47

PR: https://git.openjdk.org/jdk22/pull/47

From iris at openjdk.org  Wed Jan 10 00:24:25 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 10 Jan 2024 00:24:25 GMT
Subject: [jdk22] RFR: 8320919: Clarify Locale related system properties
In-Reply-To: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
References: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
Message-ID: <JFRmvMja10R9ecySA50ueSJT92hQCDgZji_yVHk3uHM=.34e3d47c-9712-44db-8da4-e2370606c756@github.com>

On Tue, 9 Jan 2024 23:55:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document clarification to JDK22

Confirmed that this change corresponds to the changes in main-line and the previously approved CSR.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/47#pullrequestreview-1812224747

From jpai at openjdk.org  Wed Jan 10 02:14:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Jan 2024 02:14:23 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC [v2]
In-Reply-To: <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
 <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>
Message-ID: <Xcvm2TeTPrtXpbUWY6Z_lJ8s99EDx4LB8VUnDQN8XC0=.e5f2d314-0c00-455e-babc-02224f3745c5@github.com>

On Tue, 9 Jan 2024 11:08:39 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> As per conversation in the issue.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updating copyright year for zgc and zgc-gen problem lists
>  - Removing OOMEInAQS from zgc and zgc-gen problem lists

Hello Viktor, the changes look OK to me.

This test resides in `tier1`, so if not already done, then I would suggest running tier1 once to be sure there are no unexpected issues and given that this is a GC reliant test then additionally running only this test in the CI, with a --test-repeat of something like 50, might also be a good way to see if there any intermittent failures.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17313#pullrequestreview-1812300499

From dholmes at openjdk.org  Wed Jan 10 05:59:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Jan 2024 05:59:19 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC [v2]
In-Reply-To: <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
 <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>
Message-ID: <-jzQ3_oCtFDr9yKI66KFSa6WyPMEOhtH0gSWwNGuU7U=.f78c6470-1d64-4205-adc2-3bcbd7ed9b16@github.com>

On Tue, 9 Jan 2024 11:08:39 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> As per conversation in the issue.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updating copyright year for zgc and zgc-gen problem lists
>  - Removing OOMEInAQS from zgc and zgc-gen problem lists

Looks good. Restricting to only using G1, which has not been failing, seems the best thing to do here.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17313#pullrequestreview-1812464169

From darcy at openjdk.org  Wed Jan 10 06:05:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Jan 2024 06:05:40 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier
Message-ID: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>

Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

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

Commit messages:
 - JDK-8322979: Add informative discussion to Modifier

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

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

From davidalayachew at gmail.com  Wed Jan 10 06:05:57 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 10 Jan 2024 01:05:57 -0500
Subject: Gatherers -- conditionalWindowFixed?
Message-ID: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>

Hello Core Libs Dev Team,

I have been reading through JEP 461 (https://openjdk.org/jeps/461) about
Gatherers, and I'm really excited for what this will enable for us.

By far, the most important functionality that this API facilitates is the
ability to create windows. Anytime I needed a window, I was basically
forced to use a for loop. Now, the 2 most common window cases are being
handed to us for free. It is very much appreciated.

Could we add one more method for a conditionalWindowFixed? We would need to
pass in some Predicate<T>. If the predicate returns true, create a list (if
it does not already exist) then add the element to it. If the predicate
returns false while the list is empty, then just move along to the next.
Else if the predicate returns false while the list is non empty, pass the
list down into the stream. So, you end up with Stream<T> ----->
Stream<List<T>>.

The reason I think this is worth adding is because it facilitates a really
common use case. We may not want all windows to be the same size.

Is this something worth adding to the Gatherers API?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/48697901/attachment.htm>

From davidalayachew at gmail.com  Wed Jan 10 06:17:42 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 10 Jan 2024 01:17:42 -0500
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
Message-ID: <CAA9v-_NjAkr6D7DxAfP4epV=Wfq6+Zvwp87WzxNRjZZqM9Z=mQ@mail.gmail.com>

Oh, I made a mistake. Let me try it again.

If the predicate is true, add the element to the current list (create list
prior if needed). Else if the predicate is false, send the list down to the
stream, then add the element to a new list (the new current list, if you
will).


On Wed, Jan 10, 2024 at 1:05?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Core Libs Dev Team,
>
> I have been reading through JEP 461 (https://openjdk.org/jeps/461) about
> Gatherers, and I'm really excited for what this will enable for us.
>
> By far, the most important functionality that this API facilitates is the
> ability to create windows. Anytime I needed a window, I was basically
> forced to use a for loop. Now, the 2 most common window cases are being
> handed to us for free. It is very much appreciated.
>
> Could we add one more method for a conditionalWindowFixed? We would need
> to pass in some Predicate<T>. If the predicate returns true, create a list
> (if it does not already exist) then add the element to it. If the predicate
> returns false while the list is empty, then just move along to the next.
> Else if the predicate returns false while the list is non empty, pass the
> list down into the stream. So, you end up with Stream<T> ----->
> Stream<List<T>>.
>
> The reason I think this is worth adding is because it facilitates a really
> common use case. We may not want all windows to be the same size.
>
> Is this something worth adding to the Gatherers API?
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/361df809/attachment-0001.htm>

From davidalayachew at gmail.com  Wed Jan 10 06:19:26 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 10 Jan 2024 01:19:26 -0500
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <CAA9v-_NjAkr6D7DxAfP4epV=Wfq6+Zvwp87WzxNRjZZqM9Z=mQ@mail.gmail.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <CAA9v-_NjAkr6D7DxAfP4epV=Wfq6+Zvwp87WzxNRjZZqM9Z=mQ@mail.gmail.com>
Message-ID: <CAA9v-_OiV8PUC5i29YDmYj6=s7RmYVzC6m5KcK9+Ph1bs=UcbQ@mail.gmail.com>

And this may also be better named as a split method instead of the long
conditionalWindowFixed.

On Wed, Jan 10, 2024 at 1:17?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Oh, I made a mistake. Let me try it again.
>
> If the predicate is true, add the element to the current list (create list
> prior if needed). Else if the predicate is false, send the list down to the
> stream, then add the element to a new list (the new current list, if you
> will).
>
>
> On Wed, Jan 10, 2024 at 1:05?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello Core Libs Dev Team,
>>
>> I have been reading through JEP 461 (https://openjdk.org/jeps/461) about
>> Gatherers, and I'm really excited for what this will enable for us.
>>
>> By far, the most important functionality that this API facilitates is the
>> ability to create windows. Anytime I needed a window, I was basically
>> forced to use a for loop. Now, the 2 most common window cases are being
>> handed to us for free. It is very much appreciated.
>>
>> Could we add one more method for a conditionalWindowFixed? We would need
>> to pass in some Predicate<T>. If the predicate returns true, create a list
>> (if it does not already exist) then add the element to it. If the predicate
>> returns false while the list is empty, then just move along to the next.
>> Else if the predicate returns false while the list is non empty, pass the
>> list down into the stream. So, you end up with Stream<T> ----->
>> Stream<List<T>>.
>>
>> The reason I think this is worth adding is because it facilitates a
>> really common use case. We may not want all windows to be the same size.
>>
>> Is this something worth adding to the Gatherers API?
>>
>> Thank you for your time and help!
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/8fed09a8/attachment.htm>

From sundar at openjdk.org  Wed Jan 10 06:40:32 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 10 Jan 2024 06:40:32 GMT
Subject: [jdk22] RFR: 8310995: missing @since tags in 36 jdk.dynalink classes
Message-ID: <eHc_Kt5oyWHh_mNpQ3Hbux8yFIXP51dkeToCdEO4oNM=.92342466-7dda-4dc3-8bfd-936644505284@github.com>

backported from jdk mainline "as is" without any modifications.

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

Commit messages:
 - Backport 176606d0cb9117ca9080261f898cd57339fa5a85

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

PR: https://git.openjdk.org/jdk22/pull/49

From forax at univ-mlv.fr  Wed Jan 10 07:19:15 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 10 Jan 2024 08:19:15 +0100 (CET)
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <CAA9v-_OiV8PUC5i29YDmYj6=s7RmYVzC6m5KcK9+Ph1bs=UcbQ@mail.gmail.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <CAA9v-_NjAkr6D7DxAfP4epV=Wfq6+Zvwp87WzxNRjZZqM9Z=mQ@mail.gmail.com>
 <CAA9v-_OiV8PUC5i29YDmYj6=s7RmYVzC6m5KcK9+Ph1bs=UcbQ@mail.gmail.com>
Message-ID: <1042409620.98224982.1704871155132.JavaMail.zimbra@univ-eiffel.fr>

Hello David, 
testing the gatherer api, I also wanted a "window" operation as the one you are describing. 

My use cases is a text file with some sections containing items organized like this 

:section1 
item1 
item2 
item3 
:section2 
item1 
item2 
... 

For me the signature of such method, windowGroupBy??, should take a Predicate (is a section, so the reverse of what you are suggesting) and a function that take a value (for which the predicate is true) and return a Collector, 
so I can write something like 

record Section(String name, List<String> items) {} 
String input = ... 
List<Section> sections = input.lines() 
.gather(Gatherers.windowGroupBy(line -> line.startsWith(":"), name -> Collectors. collectingAndThen (Collectors.toList(), list -> new Section(name.substring(1), list)))) 
.toList(); 

regards, 
R?mi 

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, January 10, 2024 7:19:26 AM
> Subject: Re: Gatherers -- conditionalWindowFixed?

> And this may also be better named as a split method instead of the long
> conditionalWindowFixed.

> On Wed, Jan 10, 2024 at 1:17 AM David Alayachew < [
> mailto:davidalayachew at gmail.com | davidalayachew at gmail.com ] > wrote:

>> Oh, I made a mistake. Let me try it again.

>> If the predicate is true, add the element to the current list (create list prior
>> if needed). Else if the predicate is false, send the list down to the stream,
>> then add the element to a new list (the new current list, if you will).

>> On Wed, Jan 10, 2024 at 1:05 AM David Alayachew < [
>> mailto:davidalayachew at gmail.com | davidalayachew at gmail.com ] > wrote:

>>> Hello Core Libs Dev Team,

>>> I have been reading through JEP 461 ( [ https://openjdk.org/jeps/461 |
>>> https://openjdk.org/jeps/461 ] ) about Gatherers, and I'm really excited for
>>> what this will enable for us.

>>> By far, the most important functionality that this API facilitates is the
>>> ability to create windows. Anytime I needed a window, I was basically forced to
>>> use a for loop. Now, the 2 most common window cases are being handed to us for
>>> free. It is very much appreciated.

>>> Could we add one more method for a conditionalWindowFixed? We would need to pass
>>> in some Predicate<T>. If the predicate returns true, create a list (if it does
>>> not already exist) then add the element to it. If the predicate returns false
>>> while the list is empty, then just move along to the next. Else if the
>>> predicate returns false while the list is non empty, pass the list down into
>>> the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

>>> The reason I think this is worth adding is because it facilitates a really
>>> common use case. We may not want all windows to be the same size.

>>> Is this something worth adding to the Gatherers API?

>>> Thank you for your time and help!
>>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/6b7b38a9/attachment-0001.htm>

From alanb at openjdk.org  Wed Jan 10 07:23:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 07:23:25 GMT
Subject: [jdk22] RFR: 8322809: SystemModulesMap::classNames and moduleNames
 arrays do not match the order
In-Reply-To: <A8bIBR9I_FngBg7MUvF5w16niv6i-OzTNflY0S2uZD0=.fa0668fd-6ec5-4600-b502-cf700ad10d8f@github.com>
References: <A8bIBR9I_FngBg7MUvF5w16niv6i-OzTNflY0S2uZD0=.fa0668fd-6ec5-4600-b502-cf700ad10d8f@github.com>
Message-ID: <fAAN0siURPCteyisSdhBL9CmpQycJMYOopkk9z_40fo=.90ec3488-e36e-4ec8-94fb-84f220f7fcf1@github.com>

On Tue, 9 Jan 2024 22:16:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This pull request contains a backport of commit [f3be138e](https://github.com/openjdk/jdk/commit/f3be138eb80c9e7f6cc21afb75cda9e49b667c8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 9 Jan 2024 and was reviewed by Alan Bateman.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/46#pullrequestreview-1812555013

From alanb at openjdk.org  Wed Jan 10 08:03:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 08:03:28 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <jVPfPLpjU62M30gFPhFhehbBcJF5fIzmaQtQRhfXshk=.6afe9c36-4ef0-4ca4-8c31-b2a61c4d6882@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 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!

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/23#pullrequestreview-1812613022

From alanb at openjdk.org  Wed Jan 10 08:28:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 08:28:23 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC [v2]
In-Reply-To: <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
 <Ltf_JrWKgc6pmF78nAaAGfLtT_6GzGYzDhRZgrqCZp4=.aaaccd7e-351f-4b65-9188-e2a9fa5f80bb@github.com>
Message-ID: <bHSJvzlSuUwBaCe-jN41rSQXG5Akgf95jCVe6oXVdtU=.9cb10172-9549-4c64-bbd4-1234da5f9db5@github.com>

On Tue, 9 Jan 2024 11:08:39 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> As per conversation in the issue.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updating copyright year for zgc and zgc-gen problem lists
>  - Removing OOMEInAQS from zgc and zgc-gen problem lists

The effect of `@requires vm.gc.G1` is that the test won't be selected when there is a test run that uses a different GC. Make sense and I agree restricting this test to one GC make sense.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17313#pullrequestreview-1812651947

From jlaskey at openjdk.org  Wed Jan 10 10:21:25 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 10 Jan 2024 10:21:25 GMT
Subject: [jdk22] RFR: 8310995: missing @since tags in 36 jdk.dynalink
 classes
In-Reply-To: <eHc_Kt5oyWHh_mNpQ3Hbux8yFIXP51dkeToCdEO4oNM=.92342466-7dda-4dc3-8bfd-936644505284@github.com>
References: <eHc_Kt5oyWHh_mNpQ3Hbux8yFIXP51dkeToCdEO4oNM=.92342466-7dda-4dc3-8bfd-936644505284@github.com>
Message-ID: <eA4J91o-YPfNAPRn1FBbdGptKTaV_JddsVvxDg3Vzvo=.88dee322-b4cb-4fe1-9c33-b56f6ec40837@github.com>

On Wed, 10 Jan 2024 06:32:54 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backported from jdk mainline "as is" without any modifications.

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/49#pullrequestreview-1812872031

From eirbjo at openjdk.org  Wed Jan 10 10:35:25 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 10:35:25 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <cphfaaS6jhDe7bY_9DE5I_d0YK-qzg6nMcRODJe-h5E=.81a65a8b-fec8-4d94-a39d-c706392516fb@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
 <cphfaaS6jhDe7bY_9DE5I_d0YK-qzg6nMcRODJe-h5E=.81a65a8b-fec8-4d94-a39d-c706392516fb@github.com>
Message-ID: <N3mc6rrBbG9gCj7n5d8MxRKi_G4jEGae8VQhW8s3gs0=.d125357e-41f9-4b73-9955-a5a3fed6da8e@github.com>

On Tue, 9 Jan 2024 22:08:20 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request with a new target base 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:
>> 
>>  - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime.
>>  - Merge branch 'master' into zipfs-preserve-external-file-attrs
>>  - Preserve non-permission 'external file attributes' bits when setting posix permissions
>
> Looks correct to me, too. I also went over the changes to the test and it makes sense.

Thanks to @RealCLanger for the review and to @AlanBateman for the nod.

I'll let this linger a bit before integrating in case @LanceAndersen still wants to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1884585790

From sspitsyn at openjdk.org  Wed Jan 10 10:38:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 10:38:27 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <iUenkpGXMqIrdt_jFowJYGOpRoUuMZuBmPpVJzaEL5s=.22d71c49-c5d0-4418-b13c-0621c56c3294@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 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!

Alan, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk22/pull/23#issuecomment-1884591260

From alanb at openjdk.org  Wed Jan 10 10:49:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 10:49:24 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier
In-Reply-To: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
Message-ID: <xRZpTdnv5tnNyleCLY8XYUma4bGzqyBZdvF4UM0WMiU=.ea057666-d935-4eef-86fa-593dded35a5e@github.com>

On Wed, 10 Jan 2024 06:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

src/java.base/share/classes/java/lang/reflect/Modifier.java line 237:

> 235:      * To make a high-fidelity representation of the Java source
> 236:      * modifiers of a class or member, source-level modifiers that do
> 237:      * not <em>not</em> have a constant in the this class should be

The wording looks okay, just a repeated "not" here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17338#discussion_r1447199201

From jvernee at openjdk.org  Wed Jan 10 10:59:45 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Jan 2024 10:59:45 GMT
Subject: RFR: 8322324: java/foreign/TestStubAllocFailure.java times out
 while waiting for forked process [v2]
In-Reply-To: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>
References: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>
Message-ID: <0eB-o7A7WMDrsU1XhRX6x45ipIt1RiAW-geF9wm5nKc=.fbaaf2a2-9aee-4b64-8ff2-582b9c0f0b1c@github.com>

> The issue with this test, and the test of JDK-8322324, seems to be that the forked processes write to stderr/stdout, without this output being read before the process terminates. The buffer might fill up if the output is not being read, which means that the process will stall when writing (see stack trace in JBS issue).
> 
> `OutputAnalyzer` has ways to prevent this by continuously reading from the output streams in separate threads, but because the current code calls `Process::waitFor` before creating the `OutputAnalyzer`, we never actually read the written output of the fork, which occasionally results in a stall and subsequent timeout.
> 
> The fix proposed by this patch is to use `ProcessTools::startProcess`, instead of `ProcessBuilder::start`, which will also start the necessary reader threads, preventing a stall. Incidentally, `startProcess` also has built-in timeout handling which we can use.
> 
> Testing:
> -  500 runs of both java/foreign/TestStubAllocFailure.java and java/foreign/critical/TestCriticalUpcall on various Windows x64 hosts (100 iterations was enough to observe the failure twice).
> -  `jdk_foreign` suite.

Jorn Vernee 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/17324/files
  - new: https://git.openjdk.org/jdk/pull/17324/files/2ba2851c..58f5cabf

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

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

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

From prappo at openjdk.org  Wed Jan 10 11:01:24 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 10 Jan 2024 11:01:24 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier
In-Reply-To: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
Message-ID: <nWRuECg40mF-hrg0W0bXRoifp2GIsMZMu5LDnygTrK8=.208cfb34-6d54-4fe1-a38e-3b07e369bcff@github.com>

On Wed, 10 Jan 2024 06:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

src/java.base/share/classes/java/lang/reflect/Modifier.java line 237:

> 235:      * To make a high-fidelity representation of the Java source
> 236:      * modifiers of a class or member, source-level modifiers that do
> 237:      * not <em>not</em> have a constant in the this class should be

Suggestion:

     * <em>not</em> have a constant in this class should be

src/java.base/share/classes/java/lang/reflect/Modifier.java line 238:

> 236:      * modifiers of a class or member, source-level modifiers that do
> 237:      * not <em>not</em> have a constant in the this class should be
> 238:      * included and ordered consistent with the full recommended

Suggestion:

     * included and ordered consistently with the full recommended

src/java.base/share/classes/java/lang/reflect/Modifier.java line 243:

> 241:      * {@linkplain Method#toGenericString() method} the "{@link
> 242:      * Method#isDefault() default}" modifier is ordered immediately
> 243:      * before "{@code static}" (JLS {@jls 9.4}). For a {@linkplain

Nothing wrong with that, but note that unlike other similar sections, for whatever reason, JLS 9.4 does **not** suggest this:
> If two or more (distinct) ... modifiers appear in a ... declaration, it is customary, though not required, that they appear in the order consistent with that shown above in the production for ...

I [mused] about the reasons behind it recently, but only JLS experts know them for sure. (CC'in @dansmithcode)

[mused]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117398.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17338#discussion_r1447162013
PR Review Comment: https://git.openjdk.org/jdk/pull/17338#discussion_r1447165140
PR Review Comment: https://git.openjdk.org/jdk/pull/17338#discussion_r1447218402

From prappo at openjdk.org  Wed Jan 10 11:27:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 10 Jan 2024 11:27:53 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@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 pull request now contains 20 commits:

 - Use Integer.compareUnsigned
 - Update copyright years and headers
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - 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.
 - ... and 10 more: https://git.openjdk.org/jdk/compare/bc05893f...08e6adca

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

Changes: https://git.openjdk.org/jdk/pull/14630/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=10
  Stats: 527 lines in 6 files changed: 500 ins; 16 del; 11 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 sundar at openjdk.org  Wed Jan 10 11:34:27 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 10 Jan 2024 11:34:27 GMT
Subject: [jdk22] Integrated: 8310995: missing @since tags in 36 jdk.dynalink
 classes
In-Reply-To: <eHc_Kt5oyWHh_mNpQ3Hbux8yFIXP51dkeToCdEO4oNM=.92342466-7dda-4dc3-8bfd-936644505284@github.com>
References: <eHc_Kt5oyWHh_mNpQ3Hbux8yFIXP51dkeToCdEO4oNM=.92342466-7dda-4dc3-8bfd-936644505284@github.com>
Message-ID: <ZmtLwceAboaDJkfK_dB8Ensv9iANWWBoIzg_61TCSKI=.691b3759-86ce-410b-9846-4e79a34cd823@github.com>

On Wed, 10 Jan 2024 06:32:54 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backported from jdk mainline "as is" without any modifications.

This pull request has now been integrated.

Changeset: 33f07b56
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/33f07b56ef6d519569f4345d789288022e2a28de
Stats:     38 lines in 37 files changed: 38 ins; 0 del; 0 mod

8310995: missing @since tags in 36 jdk.dynalink classes

Reviewed-by: jlaskey
Backport-of: 176606d0cb9117ca9080261f898cd57339fa5a85

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

PR: https://git.openjdk.org/jdk22/pull/49

From asotona at openjdk.org  Wed Jan 10 12:18:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 10 Jan 2024 12:18:56 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v11]
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: <za_LPOGW8Ra-inVozfKVw0i13BzALzt9eu4iKDHdPfE=.36fe6548-67e4-4388-9c57-ef39f77430cb@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:

  Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/e9bf7d57..48c2e6bc

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

  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 stefank at openjdk.org  Wed Jan 10 12:26:32 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Jan 2024 12:26:32 GMT
Subject: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
Message-ID: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>

TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

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

Commit messages:
 - Revert unrelated changes
 - 8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups

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

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

From dholmes at openjdk.org  Wed Jan 10 12:26:33 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Jan 2024 12:26:33 GMT
Subject: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
In-Reply-To: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
References: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
Message-ID: <rKod4QyiAhifogZ-pQFCREc03_xqJH8u9FkK7CHOcaM=.2acd90b7-ca69-4f91-ac53-81e76c0c3a6a@github.com>

On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

TEST.groups change is good but the other file shouldn't be there.

I will hit approve anyway and assume you will fix, as I have to go.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17344#pullrequestreview-1813099354

From stefank at openjdk.org  Wed Jan 10 12:26:34 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Jan 2024 12:26:34 GMT
Subject: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
In-Reply-To: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
References: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
Message-ID: <1SQLwEN60XAFXfCQTbyXRSM__4lEPhu-Fhhth_LCkX4=.247b7eed-35a5-427c-b9d9-09271b3a1664@github.com>

On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

Thanks. The unrelated change has been reverted.

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

PR Comment: https://git.openjdk.org/jdk/pull/17344#issuecomment-1884749086

From shade at openjdk.org  Wed Jan 10 12:33:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Jan 2024 12:33:20 GMT
Subject: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
In-Reply-To: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
References: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
Message-ID: <aSbH467nFAx-zsX8udcGPB42WTjd0cXKVmF3ng6J0SQ=.70a7a214-e4db-4e3b-bb9b-c950a1a43911@github.com>

On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17344#pullrequestreview-1813120038

From forax at univ-mlv.fr  Wed Jan 10 12:37:36 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 10 Jan 2024 13:37:36 +0100 (CET)
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <1042409620.98224982.1704871155132.JavaMail.zimbra@univ-eiffel.fr>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <CAA9v-_NjAkr6D7DxAfP4epV=Wfq6+Zvwp87WzxNRjZZqM9Z=mQ@mail.gmail.com>
 <CAA9v-_OiV8PUC5i29YDmYj6=s7RmYVzC6m5KcK9+Ph1bs=UcbQ@mail.gmail.com>
 <1042409620.98224982.1704871155132.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <1251490073.98715418.1704890256361.JavaMail.zimbra@univ-eiffel.fr>

> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "David Alayachew" <davidalayachew at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, January 10, 2024 8:19:15 AM
> Subject: Re: Gatherers -- conditionalWindowFixed?

> Hello David,
> testing the gatherer api, I also wanted a "window" operation as the one you are
> describing.

> My use cases is a text file with some sections containing items organized like
> this

> :section1
> item1
> item2
> item3
> :section2
> item1
> item2
> ...

> For me the signature of such method, windowGroupBy??, should take a Predicate
> (is a section, so the reverse of what you are suggesting) and a function that
> take a value (for which the predicate is true) and return a Collector,
> so I can write something like

> record Section(String name, List<String> items) {}
> String input = ...
> List<Section> sections = input.lines()
> .gather(Gatherers.windowGroupBy(line -> line.startsWith(":"), name ->
> Collectors. collectingAndThen (Collectors.toList(), list -> new
> Section(name.substring(1), list))))
> .toList();

Thinking a little more, having a function that returns a Collector is a kind of an anti-pattern, it would be better to decouple the function that creates the section and the collector, so the same collector is re-used. 
So windowGroupBy?? should take a predicate, a collector and a function that takes the value (for which the predicate is true) and the result of the collector. 

< T , R , R2 > Gatherer < T , ?, R2 > windowGroupBy ( Predicate <? super T > predicate , Collector <? super T , ?, ? extends R > collector , BiFunction <? super T , ? super R , ? extends R2 > mapper ) 

R?mi 

>> From: "David Alayachew" <davidalayachew at gmail.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Wednesday, January 10, 2024 7:19:26 AM
>> Subject: Re: Gatherers -- conditionalWindowFixed?

>> And this may also be better named as a split method instead of the long
>> conditionalWindowFixed.

>> On Wed, Jan 10, 2024 at 1:17 AM David Alayachew < [
>> mailto:davidalayachew at gmail.com | davidalayachew at gmail.com ] > wrote:

>>> Oh, I made a mistake. Let me try it again.

>>> If the predicate is true, add the element to the current list (create list prior
>>> if needed). Else if the predicate is false, send the list down to the stream,
>>> then add the element to a new list (the new current list, if you will).

>>> On Wed, Jan 10, 2024 at 1:05 AM David Alayachew < [
>>> mailto:davidalayachew at gmail.com | davidalayachew at gmail.com ] > wrote:

>>>> Hello Core Libs Dev Team,

>>>> I have been reading through JEP 461 ( [ https://openjdk.org/jeps/461 |
>>>> https://openjdk.org/jeps/461 ] ) about Gatherers, and I'm really excited for
>>>> what this will enable for us.

>>>> By far, the most important functionality that this API facilitates is the
>>>> ability to create windows. Anytime I needed a window, I was basically forced to
>>>> use a for loop. Now, the 2 most common window cases are being handed to us for
>>>> free. It is very much appreciated.

>>>> Could we add one more method for a conditionalWindowFixed? We would need to pass
>>>> in some Predicate<T>. If the predicate returns true, create a list (if it does
>>>> not already exist) then add the element to it. If the predicate returns false
>>>> while the list is empty, then just move along to the next. Else if the
>>>> predicate returns false while the list is non empty, pass the list down into
>>>> the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

>>>> The reason I think this is worth adding is because it facilitates a really
>>>> common use case. We may not want all windows to be the same size.

>>>> Is this something worth adding to the Gatherers API?

>>>> Thank you for your time and help!
>>>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/d64ce7cf/attachment-0001.htm>

From vklang at openjdk.org  Wed Jan 10 12:47:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Jan 2024 12:47:23 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC
In-Reply-To: <9V60NQfQ9QfVbHXA4EEqmUbO_UH9Rj4uMkRAs08oYgM=.bee69737-992c-4514-854e-c15e92375e3e@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
 <9V60NQfQ9QfVbHXA4EEqmUbO_UH9Rj4uMkRAs08oYgM=.bee69737-992c-4514-854e-c15e92375e3e@github.com>
Message-ID: <betrHu2ETA7_T5ndqzEO-0MqHRSD_65OWyaZ2GdEGNo=.c4c7bafc-f613-4e37-8df4-552a39ff0c10@github.com>

On Tue, 9 Jan 2024 04:15:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> As per conversation in the issue.
>
> Hello Viktor, the skara bot very helpfully has noted that this test has been problemlisted in a couple of files:
> 
>> 8309218 is used in problem lists: [test/jdk/ProblemList-zgc.txt, test/jdk/ProblemList-generational-zgc.txt]
> 
> so this current PR which is proposing to fix that test would have to remove it from those two problem lists.

@jaikiran I've had it run tier1 (though not in a repeat loop), since the changes proposed here only affects the execution of the test and not changing the test itself, I thought it just made sense to have it run on tier1 once (after running the specific test itself on M5 100 times).

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

PR Comment: https://git.openjdk.org/jdk/pull/17313#issuecomment-1884783384

From tschatzl at openjdk.org  Wed Jan 10 12:52:25 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 10 Jan 2024 12:52:25 GMT
Subject: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
In-Reply-To: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
References: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
Message-ID: <zWfkFSkhQ3cEhS1mQs0FFHHYXGFGCUxqufV3ZMWQpM4=.d35b865b-a6f7-4e3c-acfb-dae3c6537b72@github.com>

On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17344#pullrequestreview-1813156136

From jpai at openjdk.org  Wed Jan 10 13:18:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Jan 2024 13:18:26 GMT
Subject: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still
 times out with ZGC, Generational ZGC, and SerialGC
In-Reply-To: <betrHu2ETA7_T5ndqzEO-0MqHRSD_65OWyaZ2GdEGNo=.c4c7bafc-f613-4e37-8df4-552a39ff0c10@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
 <9V60NQfQ9QfVbHXA4EEqmUbO_UH9Rj4uMkRAs08oYgM=.bee69737-992c-4514-854e-c15e92375e3e@github.com>
 <betrHu2ETA7_T5ndqzEO-0MqHRSD_65OWyaZ2GdEGNo=.c4c7bafc-f613-4e37-8df4-552a39ff0c10@github.com>
Message-ID: <WjZl9R7xoAzFGb_PP2MM5MskM5nl579vregXI4-Sah4=.8c52f810-88b1-4aca-8dfe-fe06b2b419bc@github.com>

On Wed, 10 Jan 2024 12:44:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Hello Viktor, the skara bot very helpfully has noted that this test has been problemlisted in a couple of files:
>> 
>>> 8309218 is used in problem lists: [test/jdk/ProblemList-zgc.txt, test/jdk/ProblemList-generational-zgc.txt]
>> 
>> so this current PR which is proposing to fix that test would have to remove it from those two problem lists.
>
> @jaikiran I've had it run tier1 (though not in a repeat loop), since the changes proposed here only affects the execution of the test and not changing the test itself, I thought it just made sense to have it run on tier1 once (after running the specific test itself on M5 100 times).

@viktorklang-ora  that sounds good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/17313#issuecomment-1884831843

From jvernee at openjdk.org  Wed Jan 10 13:18:28 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Jan 2024 13:18:28 GMT
Subject: Integrated: 8322324: java/foreign/TestStubAllocFailure.java times out
 while waiting for forked process
In-Reply-To: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>
References: <zH1nKInr7EjB2hMPKEnY-Kgzil6O1YifFdgWP6OS2P8=.a442f89c-edda-405b-a2e4-607d13a3d2fb@github.com>
Message-ID: <BJ2F6xQ6GTi3q_t3QQCRudTya1Iebfymfk1luyneqTE=.bb783644-4646-4a5d-9f11-2e2be9c35c20@github.com>

On Tue, 9 Jan 2024 14:18:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The issue with this test, and the test of JDK-8322324, seems to be that the forked processes write to stderr/stdout, without this output being read before the process terminates. The buffer might fill up if the output is not being read, which means that the process will stall when writing (see stack trace in JBS issue).
> 
> `OutputAnalyzer` has ways to prevent this by continuously reading from the output streams in separate threads, but because the current code calls `Process::waitFor` before creating the `OutputAnalyzer`, we never actually read the written output of the fork, which occasionally results in a stall and subsequent timeout.
> 
> The fix proposed by this patch is to use `ProcessTools::startProcess`, instead of `ProcessBuilder::start`, which will also start the necessary reader threads, preventing a stall. Incidentally, `startProcess` also has built-in timeout handling which we can use.
> 
> Testing:
> -  500 runs of both java/foreign/TestStubAllocFailure.java and java/foreign/critical/TestCriticalUpcall on various Windows x64 hosts (100 iterations was enough to observe the failure twice).
> -  `jdk_foreign` suite.

This pull request has now been integrated.

Changeset: d2d58dd6
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e
Stats:     16 lines in 1 file changed: 3 ins; 0 del; 13 mod

8322324: java/foreign/TestStubAllocFailure.java times out while waiting for forked process
8322637: java/foreign/critical/TestCriticalUpcall.java timed out

Reviewed-by: mcimadamore

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

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

From eirbjo at openjdk.org  Wed Jan 10 13:23:44 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 13:23:44 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v11]
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: <QZtVKKLJ5jRIKxih7f0B7ex_QP_y8cTNAUSTgRk7hAs=.76383c78-4c96-48be-9a6a-1aeb8a861876@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 Bj?rsn?s has updated the pull request incrementally with eight additional commits since the last revision:

 - Minor tweaks to improve comments
 - Tighten 64-bit data descriptor checking by requiring that the LOC's 'compressed size' and 'uncompressed size' fields must both be 0xFFFFFFFF and that the Zip64 field must have both 'Original Size' and 'Compressed' size fields present and set to zero.
 - Add test verifying that the data descriptor is read with 32-bit values if neither the 'compressed size' or 'uncompressed size' are set to the Zip64 magic marker value.
 - Rename hasZip64Extra to expect64BitDataDescriptor, make it return false if the LOC is not in streaming mode, if none of the LOC size fields have the Zip64 magic value set, or if the Zip64 data block size does not match the size computed from looking for markers in the LOC fields.
 - Move the call to hasZip64Extra from readEND to readLOC
 - Add a test verifying that a truncated Zip64 field (one with less than 4 bytes) is ignored and does not cause a ArrayIndexOutOfBoundsException.
 - When verifying that invalid Zip64 fields are ignored, use a separate ZIP with regular 4-bit data descriptors.
 - Avoid ArrayIndexOutOfBoundsException in the case were the LOC extra field ends with a truncated Zip64 field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/900c5b19..8a44feb5

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

  Stats: 196 lines in 2 files changed: 125 ins; 17 del; 54 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 eirbjo at openjdk.org  Wed Jan 10 13:23:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 13:23:46 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v10]
In-Reply-To: <R7qjZwqzM0CD8WJ3FlF3Oe2fkcWmqIWWohMsVBfg7Wo=.957a5ff4-99f3-4009-80ac-2d689cd1b47d@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <R7qjZwqzM0CD8WJ3FlF3Oe2fkcWmqIWWohMsVBfg7Wo=.957a5ff4-99f3-4009-80ac-2d689cd1b47d@github.com>
Message-ID: <c9ersZ1p1h3v2t46e5JWg_9ZNNIKNwKI-Lqw58D6hcY=.e0a86830-ed44-4972-bd63-f372cefd5a08@github.com>

On Tue, 9 Jan 2024 13:06:56 GMT, Eirik Bj?rsn?s <eirbjo 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move hasZip64Extra(e) to the end of the 4/8-byte data descriptor check
>  - hasZip64 does not throw IOException

Marking this PR ready for review again with the following changes applied:

- The decision of whether to expect 64 bit data descriptors is moved from `readEnd` to `readLOC`. This allows access to the 'compressed size' and 'uncompressed size' of the LOC as well as direct access to the extra data, remediating concerns raised by @jaikiran about trusting any passed `ZipEntry` extra data.
- Checking of LOC is tightened to require that the 'compressed size' and 'uncompressed size' fields are both set to the Zip64 magic marker 0xFFFFFFFF (Required for Zip64 entries)
- Checking of the Zip64 field is tightened to require that the 'Original Size' and 'Compressed Size' are both present and set to zero. (Required for Zip64 entires using Data Descriptors)
- An new internal boolean field `ZipInputStream.expect64BitDataDescriptor` passes the decision made in `readLOC` on to the `readEnd` method.

The two support methods added by the PR have been renamed:

- `hasZip64Extra` is now called `expect64BitDataDescriptor`
- `isZip64ExtBlockSizeValid` is now called `isZip64DataDescriptorField`

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

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

From stefank at openjdk.org  Wed Jan 10 13:28:31 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Jan 2024 13:28:31 GMT
Subject: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
In-Reply-To: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
References: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
Message-ID: <6bOyJlxxLDykmaE34rv3xdlE3K3Tx9cPWd_L3HC66qI=.1faecd1e-24df-4002-a734-d511c92283c0@github.com>

On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17344#issuecomment-1884845496

From stefank at openjdk.org  Wed Jan 10 13:28:32 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 Jan 2024 13:28:32 GMT
Subject: Integrated: 8323508: Remove TestGCLockerWithShenandoah.java line from
 TEST.groups
In-Reply-To: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
References: <l0ljTvkDAPAwDySi9JM8BHKBxUPEfbNPOUy2j6kx-ek=.0a95de87-5c71-419d-98ab-a45cc1edac14@github.com>
Message-ID: <hGyiQYpFH2sW7aY8kl0uzYG_jA4SW6V6vxPV8uOntlg=.40271205-036c-46b0-b76a-4c536f8fadab@github.com>

On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file still has a reference to it. This causes problems in our CI pipeline.

This pull request has now been integrated.

Changeset: ec385057
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec38505720251ceefc8e838bd68b740d166c83c1
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups

Reviewed-by: dholmes, shade, tschatzl

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

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

From viktor.klang at oracle.com  Wed Jan 10 13:33:45 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 10 Jan 2024 13:33:45 +0000
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
Message-ID: <MW4PR10MB5774AA5CEDA7B1FEFDA4D07BFF692@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David!

Apologies for the late reply, there's been lots of catching up to do after the holidays.

>I'm really excited for what this will enable for us.

I'm really glad to hear that ?

>It is very much appreciated.

?

> Could we add one more method for a conditionalWindowFixed? We would need to pass in some Predicate<T>. If the predicate returns true, create a list (if it does not already exist) then add the element to it. If the predicate returns false while the list is empty, then just move along to the next. Else if the predicate returns false while the list is non empty, pass the list down into the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

What ends up under Gatherers.* does require careful triaging, ideally by first seeing user-created implementations being heavily used/useful, then potential candidate for Gatherers.*, and then at the end it might end up in Stream as a dedicated method.

By virtue of the Gatherers API, it seems pretty straight-forward for you to implement what you describe, and personally I'd probably call it something like windowBy.

Just typing this up as I write this reply, it could look something like this:

<TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR> includeInCurrentWindow) {
  class State {
    ArrayList<TR> window;

    boolean integrate(TR element, Gatherer.Downstream<? super List<TR>> downstream) {
      if (window != null && !includeInCurrentWindow.test(element)) {
        var result = Collections.unmodifiableList(window);
        window = null;
        if (!downstream.push(result))
          return false;
      }

      if (window == null)
        window = new ArrayList<>();

      return window.add(element);
    }

    void finish(Gatherer.Downstream<? super List<TR>> downstream) {
      if (window != null) {
        var result = Collections.unmodifiableList(window);
        window = null;
        downstream.push(result);
      }
    }
  }
  return Gatherer.<TR, State, List<TR>>ofSequential(State::new, State::integrate, State::finish);
}

jshell> Stream.of("header", "value1", "value2", "header", "header", "value 3", "value 4", null).gather(windowBy(Predicate.not("header"::equals))).toList()
$1 ==> [[header, value1, value2], [header], [header, value 3, value 4, null]]


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Wednesday, 10 January 2024 07:05
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Gatherers -- conditionalWindowFixed?

Hello Core Libs Dev Team,

I have been reading through JEP 461 (https://openjdk.org/jeps/461) about Gatherers, and I'm really excited for what this will enable for us.

By far, the most important functionality that this API facilitates is the ability to create windows. Anytime I needed a window, I was basically forced to use a for loop. Now, the 2 most common window cases are being handed to us for free. It is very much appreciated.

Could we add one more method for a conditionalWindowFixed? We would need to pass in some Predicate<T>. If the predicate returns true, create a list (if it does not already exist) then add the element to it. If the predicate returns false while the list is empty, then just move along to the next. Else if the predicate returns false while the list is non empty, pass the list down into the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

The reason I think this is worth adding is because it facilitates a really common use case. We may not want all windows to be the same size.

Is this something worth adding to the Gatherers API?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/ee085203/attachment.htm>

From eirbjo at openjdk.org  Wed Jan 10 13:39:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 13:39:52 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
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: <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Remove trailing whitespace
 - Remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/8a44feb5..91fbcce5

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 rgiulietti at openjdk.org  Wed Jan 10 13:54:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 13:54:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <HECLeGNZfOMdoMkYhCtvkfLLvyX2CbR9jRMASwL23fE=.3780d393-9077-4be4-9c02-f9f78a254be0@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
 <HECLeGNZfOMdoMkYhCtvkfLLvyX2CbR9jRMASwL23fE=.3780d393-9077-4be4-9c02-f9f78a254be0@github.com>
Message-ID: <4QouJOP9lPBgzMxFuVvxBVmlaGGAu27nQDr2RGfgQHo=.dce3c918-fe2e-4190-9c53-f31cdfbf3088@github.com>

On Tue, 9 Jan 2024 18:31:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yes, that's perhaps clearer, will do.
>
> Typically in other places in the JDK we use `priviledgedXxx` for naming methods that are simple wrappers that call `xxx` from within a `doPrivileged`. The method is called privileged because it doesn't require the caller to use `doPrivileged`.
> 
> That is something like:
> 
> 
> String privilegedGetProperty(String property) {
>      return AccessController.doPrivileged((...) () -> System.getProperty(property));
> } 
> 
> 
> See for instance: https://github.com/openjdk/jdk/blob/ee98d262181f5822609674c71c85ad4576ac1632/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L107

Ah OK, I wasn't aware of this convention.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447413819

From jvernee at openjdk.org  Wed Jan 10 14:14:23 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Jan 2024 14:14:23 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <X0Mc-zqhO931z5lcBwsHDKMY0mVRvnJL1WEdw5_0lfc=.de4c0b11-aaa2-4ccd-89f4-f144f413a6ce@github.com>

On Mon, 8 Jan 2024 16:16:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

src/java.base/share/classes/java/lang/foreign/Arena.java line 269:

> 267:      * @implSpec
> 268:      * Implementations of this method must return a native, zero-initialized segment
> 269:      * featuring the requested size, and that is compatible with the provided alignment

Do we want to _mandate_ that all arenas return zero-initialized memory? Maybe it's enough to say that the default implementation does this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1447440934

From mcimadamore at openjdk.org  Wed Jan 10 14:24:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 14:24:24 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <X0Mc-zqhO931z5lcBwsHDKMY0mVRvnJL1WEdw5_0lfc=.de4c0b11-aaa2-4ccd-89f4-f144f413a6ce@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <X0Mc-zqhO931z5lcBwsHDKMY0mVRvnJL1WEdw5_0lfc=.de4c0b11-aaa2-4ccd-89f4-f144f413a6ce@github.com>
Message-ID: <cdyIItIR1GPTvWjFFNJ_P4tcg6FyNUWFhMX8YKJdk6M=.f6a9851e-db87-4a67-85a7-abdcf695c3ed@github.com>

On Wed, 10 Jan 2024 14:12:02 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
>> 
>> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 269:
> 
>> 267:      * @implSpec
>> 268:      * Implementations of this method must return a native, zero-initialized segment
>> 269:      * featuring the requested size, and that is compatible with the provided alignment
> 
> Do we want to _mandate_ that all arenas return zero-initialized memory? Maybe it's enough to say that the default implementation does this.

It's not a default method. That said, according to this suggestion it could be possible to move the text in the ofAuto/ofConfined/ofArena factories.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1447449904

From mcimadamore at openjdk.org  Wed Jan 10 14:24:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 14:24:24 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <cdyIItIR1GPTvWjFFNJ_P4tcg6FyNUWFhMX8YKJdk6M=.f6a9851e-db87-4a67-85a7-abdcf695c3ed@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <X0Mc-zqhO931z5lcBwsHDKMY0mVRvnJL1WEdw5_0lfc=.de4c0b11-aaa2-4ccd-89f4-f144f413a6ce@github.com>
 <cdyIItIR1GPTvWjFFNJ_P4tcg6FyNUWFhMX8YKJdk6M=.f6a9851e-db87-4a67-85a7-abdcf695c3ed@github.com>
Message-ID: <Ac-UpoOkyccEId5VlgODBi6Ys7em1wJR6pN6VUcUbus=.114261e7-b56c-4aea-8c48-a94d7301fef2@github.com>

On Wed, 10 Jan 2024 14:19:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Arena.java line 269:
>> 
>>> 267:      * @implSpec
>>> 268:      * Implementations of this method must return a native, zero-initialized segment
>>> 269:      * featuring the requested size, and that is compatible with the provided alignment
>> 
>> Do we want to _mandate_ that all arenas return zero-initialized memory? Maybe it's enough to say that the default implementation does this.
>
> It's not a default method. That said, according to this suggestion it could be possible to move the text in the ofAuto/ofConfined/ofArena factories.

The choice here is: if we allow non-zeroing implementation, implementors of Arena have more flexibility, but clients have less guarantees (how does a client know if what they get back is zeroed?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1447452246

From jvernee at openjdk.org  Wed Jan 10 14:32:20 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Jan 2024 14:32:20 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <Ac-UpoOkyccEId5VlgODBi6Ys7em1wJR6pN6VUcUbus=.114261e7-b56c-4aea-8c48-a94d7301fef2@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <X0Mc-zqhO931z5lcBwsHDKMY0mVRvnJL1WEdw5_0lfc=.de4c0b11-aaa2-4ccd-89f4-f144f413a6ce@github.com>
 <cdyIItIR1GPTvWjFFNJ_P4tcg6FyNUWFhMX8YKJdk6M=.f6a9851e-db87-4a67-85a7-abdcf695c3ed@github.com>
 <Ac-UpoOkyccEId5VlgODBi6Ys7em1wJR6pN6VUcUbus=.114261e7-b56c-4aea-8c48-a94d7301fef2@github.com>
Message-ID: <oy4TCgS_NEklN68vi4KmpUtMiBRzWDLaQPDd6tniSts=.6f524a01-c6ef-4f18-9a37-6fe902c24903@github.com>

On Wed, 10 Jan 2024 14:21:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> (how does a client know if what they get back is zeroed?)

It seems similar to e.g. a HashMap vs. LinkedHashMap with regards to ordering. The creator of the Arena would decide the zeroing strategy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1447463240

From mcimadamore at openjdk.org  Wed Jan 10 14:41:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 14:41:21 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <oy4TCgS_NEklN68vi4KmpUtMiBRzWDLaQPDd6tniSts=.6f524a01-c6ef-4f18-9a37-6fe902c24903@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <X0Mc-zqhO931z5lcBwsHDKMY0mVRvnJL1WEdw5_0lfc=.de4c0b11-aaa2-4ccd-89f4-f144f413a6ce@github.com>
 <cdyIItIR1GPTvWjFFNJ_P4tcg6FyNUWFhMX8YKJdk6M=.f6a9851e-db87-4a67-85a7-abdcf695c3ed@github.com>
 <Ac-UpoOkyccEId5VlgODBi6Ys7em1wJR6pN6VUcUbus=.114261e7-b56c-4aea-8c48-a94d7301fef2@github.com>
 <oy4TCgS_NEklN68vi4KmpUtMiBRzWDLaQPDd6tniSts=.6f524a01-c6ef-4f18-9a37-6fe902c24903@github.com>
Message-ID: <raZhXcPF98TpPn9QQAIImR0LhWmAbvBpV0BK_hxtUyU=.1a42140b-eba3-4903-987e-dbf1cf85d95b@github.com>

On Wed, 10 Jan 2024 14:29:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The choice here is: if we allow non-zeroing implementation, implementors of Arena have more flexibility, but clients have less guarantees (how does a client know if what they get back is zeroed?)
>
>> (how does a client know if what they get back is zeroed?)
> 
> It seems similar to e.g. a HashMap vs. LinkedHashMap with regards to ordering. The creator of the Arena would decide the zeroing strategy.

Not sure if that analogy is 100% correct. In that case a client that takes a `Map`, but wants order, can say to accept e.g. a `SequencedMap`. In the case of `Arena`, there's no subtype which adds the "zeroing" characteristics. So a client accepting an arena, and doing some allocation would be effectively at the mercy of who created the arena. I think one can argue this both ways.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1447474611

From rriggs at openjdk.org  Wed Jan 10 14:51:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 14:51:29 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
Message-ID: <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>

On Wed, 10 Jan 2024 11:27:53 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 pull request now contains 20 commits:
> 
>  - Use Integer.compareUnsigned
>  - Update copyright years and headers
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - 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.
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/bc05893f...08e6adca

src/java.base/share/classes/java/math/BigInteger.java line 3998:

> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
> 3997:         if (i != -1)
> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;

Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447488470

From pminborg at openjdk.org  Wed Jan 10 14:57:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 10 Jan 2024 14:57:24 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout, 
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario
In-Reply-To: <QGvbnTJ2vVVsFax-i-jxCR_EDPYPuMBKjGJ4g3pG7R8=.ea6ca818-5d6b-4d69-bb77-11b1eb304b26@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
 <QGvbnTJ2vVVsFax-i-jxCR_EDPYPuMBKjGJ4g3pG7R8=.ea6ca818-5d6b-4d69-bb77-11b1eb304b26@github.com>
Message-ID: <7ze7EKGVTIUWuwgH4iRylXmTOngPau67jBXc6t2whFU=.f00bc0bf-0ef9-43a0-9a86-a0ba9149a8ca@github.com>

On Tue, 9 Jan 2024 17:11:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1944:
> 
>> 1942:      *         in the provided layout
>> 1943:      * @throws IndexOutOfBoundsException if {@code offset > byteSize() - layout.byteSize()}
>> 1944:      *         or {@code offset < 0}
> 
> Why is UOE being removed here (and elsewhere) ?

This one is redundant and there is an IAE covering the same case a bit down.

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

PR Review Comment: https://git.openjdk.org/jdk22/pull/42#discussion_r1447497781

From rgiulietti at openjdk.org  Wed Jan 10 15:02:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 15:02:31 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
 <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>
Message-ID: <2X3g6YcSJSMN83eYD5682QY7FRs9GUKca3GULrFmQH0=.096e3518-c437-4aa5-8135-0f005bcd10e6@github.com>

On Wed, 10 Jan 2024 14:48:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Use Integer.compareUnsigned
>>  - Update copyright years and headers
>>  - Merge branch 'master' into 8310813
>>  - Merge branch 'master' into 8310813
>>  - 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.
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/bc05893f...08e6adca
>
> src/java.base/share/classes/java/math/BigInteger.java line 3998:
> 
>> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
>> 3997:         if (i != -1)
>> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;
> 
> Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
> Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.

Yes, that's what was proposed [here](https://github.com/openjdk/jdk/pull/14630#discussion_r1242245875) some time ago.

But the spec of `compareUnsigned()` does _not_ guarantee a -1, 0, 1 result, so there's a (minimal) risk when returning its value directly. (For some reason, `BigInteger` specifies a -1, 0, 1 outcome.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447502797

From rriggs at openjdk.org  Wed Jan 10 15:14:28 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 15:14:28 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v11]
In-Reply-To: <2X3g6YcSJSMN83eYD5682QY7FRs9GUKca3GULrFmQH0=.096e3518-c437-4aa5-8135-0f005bcd10e6@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9AQzCymYoG6S891OBeU6T5aIu3CRkKKF8QAiRpIRsVs=.41822b6a-e2e7-4b24-a78d-f422bcfbfccc@github.com>
 <Zkn4kgmyaiFqyORteulxu_tDV0Mz9Sy1PlxOKcRs-mI=.b9a5b8ec-7374-4cc3-b44f-b1aec27c4652@github.com>
 <2X3g6YcSJSMN83eYD5682QY7FRs9GUKca3GULrFmQH0=.096e3518-c437-4aa5-8135-0f005bcd10e6@github.com>
Message-ID: <tnjTe18cjdM5lHuXrRxx6nYfb1IFzQaf9cHf1hWLLrk=.7a0006fc-da25-4883-a0a6-07fd2f508da0@github.com>

On Wed, 10 Jan 2024 14:58:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 3998:
>> 
>>> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
>>> 3997:         if (i != -1)
>>> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;
>> 
>> Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
>> Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.
>
> Yes, that's what was proposed [here](https://github.com/openjdk/jdk/pull/14630#discussion_r1242245875) some time ago.
> 
> But the spec of `compareUnsigned()` does _not_ guarantee a -1, 0, 1 result, so there's a (minimal) risk when returning its value directly. (For some reason, `BigInteger` specifies a -1, 0, 1 outcome.)

In expressing intent, perhaps `Integer.signum(Integer.compareUnsigned(m1[i], [m2[i]))`.
Though it may all be for nothing if C2 can optimize it away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447521230

From redestad at openjdk.org  Wed Jan 10 15:21:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 10 Jan 2024 15:21:33 GMT
Subject: RFR: 8323529: Relativize test image dependencies in microbenchmarks
Message-ID: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>

JMH microbenchmarks may have dependencies on artifacts in the test image outside of the benchmarks.jar. This includes native libraries (built into `$TEST_IMAGE/micro/native`) and may soon include other test libraries like wb.jar (built into `$TEST_IMAGE/lib-test/`)

By moving execution to the test image root (currently we run out of the `make` directory) we can make do with relative paths, which means benchmark can supply a build-time constant flag themselves rather than have the test runner provide it for you. And needing to be explicit about external dependencies is good, I think.

Taken together this makes the benchmarks.jar more self-contained and simpler to run: all you need is to run `java -jar micro/benchmarks.jar` from the test image root.

This patch also drive-by fixes some lang.foreign tests that were printing warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag.

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

Commit messages:
 - 8323529: Relativize test image dependencies in microbenchmarks

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

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

From mcimadamore at openjdk.org  Wed Jan 10 15:21:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 15:21:35 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
Message-ID: <Ozf5I2CIHkivlGAlU6LrpwRF_fUaPlFSS7s11eQgaZI=.6c544c55-c788-4a3e-9e66-84d4d4573a9e@github.com>

On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> JMH microbenchmarks may have dependencies on artifacts in the test image outside of the benchmarks.jar. This includes native libraries (built into `$TEST_IMAGE/micro/native`) and may soon include other test libraries like wb.jar (built into `$TEST_IMAGE/lib-test/`)
> 
> By moving execution to the test image root (currently we run out of the `make` directory) we can make do with relative paths, which means benchmark can supply a build-time constant flag themselves rather than have the test runner provide it for you. And needing to be explicit about external dependencies is good, I think.
> 
> Taken together this makes the benchmarks.jar more self-contained and simpler to run: all you need is to run `java -jar micro/benchmarks.jar` from the test image root.
> 
> This patch also drive-by fixes some lang.foreign tests that were printing warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17349#pullrequestreview-1813465412

From mcimadamore at openjdk.org  Wed Jan 10 15:25:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 15:25:25 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout, 
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario
In-Reply-To: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
Message-ID: <DNpqE12Gj0_GQGpYbjQNk1ptp2-1uSlvVdgyO19RXiY=.a5890c39-2208-4e99-ad8a-24d50516c3c9@github.com>

On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> 8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

test/jdk/java/foreign/TestSegmentAllocators.java line 234:

> 232:             // WrongThreadException if this method is called from a thread {@code T},
> 233:             // such that {@code source.isAccessibleBy(T) == false}
> 234:             CompletableFuture<Arena> future = CompletableFuture.supplyAsync(Arena::ofConfined);

I believe TestScopedOperations should check for WTE as well?

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

PR Review Comment: https://git.openjdk.org/jdk22/pull/42#discussion_r1447535353

From mcimadamore at openjdk.org  Wed Jan 10 15:25:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 15:25:25 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout, 
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario
In-Reply-To: <DNpqE12Gj0_GQGpYbjQNk1ptp2-1uSlvVdgyO19RXiY=.a5890c39-2208-4e99-ad8a-24d50516c3c9@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
 <DNpqE12Gj0_GQGpYbjQNk1ptp2-1uSlvVdgyO19RXiY=.a5890c39-2208-4e99-ad8a-24d50516c3c9@github.com>
Message-ID: <IT6RIYtFb00w6U4qngSXnzs-OrSw7Z1GD1ZIKVLks-4=.90ed9a8a-6ab3-4952-bbc0-d83767275f05@github.com>

On Wed, 10 Jan 2024 15:22:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
>
> test/jdk/java/foreign/TestSegmentAllocators.java line 234:
> 
>> 232:             // WrongThreadException if this method is called from a thread {@code T},
>> 233:             // such that {@code source.isAccessibleBy(T) == false}
>> 234:             CompletableFuture<Arena> future = CompletableFuture.supplyAsync(Arena::ofConfined);
> 
> I believe TestScopedOperations should check for WTE as well?

That test has two methods: `testOpAfterClose` and `testOpOutsideConfinement`, which are executed on all the test cases.

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

PR Review Comment: https://git.openjdk.org/jdk22/pull/42#discussion_r1447536542

From mcimadamore at openjdk.org  Wed Jan 10 15:28:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 15:28:23 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout, 
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario
In-Reply-To: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
Message-ID: <xENDIGntKpKmzXf0kEKw2yK0mCXkPum5R28baMh0sQ0=.b9ff87e5-1b67-47fd-8eb6-eb90feaa4a4a@github.com>

On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> 8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/42#pullrequestreview-1813487165

From jvernee at openjdk.org  Wed Jan 10 15:32:23 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Jan 2024 15:32:23 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
Message-ID: <B182UcFenp-OQdDXapewdHVOSod3rGQGnxFBXP89ncg=.c968cbd2-87f2-404d-9e12-df2475ba565d@github.com>

On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> JMH microbenchmarks may have dependencies on artifacts in the test image outside of the benchmarks.jar. This includes native libraries (built into `$TEST_IMAGE/micro/native`) and may soon include other test libraries like wb.jar (built into `$TEST_IMAGE/lib-test/`)
> 
> By moving execution to the test image root (currently we run out of the `make` directory) we can make do with relative paths, which means benchmark can supply a build-time constant flag themselves rather than have the test runner provide it for you. And needing to be explicit about external dependencies is good, I think.
> 
> Taken together this makes the benchmarks.jar more self-contained and simpler to run: all you need is to run `java -jar micro/benchmarks.jar` from the test image root.
> 
> This patch also drive-by fixes some lang.foreign tests that were printing warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17349#pullrequestreview-1813501669

From rgiulietti at openjdk.org  Wed Jan 10 15:43:46 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 15:43:46 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v13]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@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 reviewers feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/9ca1f36d..ff1b7068

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

  Stats: 66 lines in 2 files changed: 27 ins; 10 del; 29 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 vklang at openjdk.org  Wed Jan 10 16:12:29 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Jan 2024 16:12:29 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v4]
In-Reply-To: <JvpXTdUylo-lBIa57VvYzHGWB7TKUFfg-J5xsKb6tVc=.7d9aef07-3a4d-44b0-a79e-27201f5d8b1e@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <JvpXTdUylo-lBIa57VvYzHGWB7TKUFfg-J5xsKb6tVc=.7d9aef07-3a4d-44b0-a79e-27201f5d8b1e@github.com>
Message-ID: <bEgsmocaPXKYIS7whfKr7Gp5DratkzYprNB5PUv0fKM=.8a2fbf82-0a8b-4890-8b1c-a606ff2fd991@github.com>

On Tue, 12 Dec 2023 23:36:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 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

src/java.base/share/classes/java/lang/ref/Reference.java line 499:

> 497:      * the reference is removed from the queue by {@link ReferenceQueue#poll}
> 498:      * or {@link ReferenceQueue#remove}. An <b><i>unsuccessful</i></b>
> 499:      * {@code enqueue} call has no memory consistency effects.

Would it help to say that unsuccessful enqueue calls have no *reliable* or *specified* memory consistency effects?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1447602550

From dfuchs at openjdk.org  Wed Jan 10 16:23:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 16:23:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <cQ1yj8jICgoS6Sl7hq-s3L3wKA5ZK9dUmMldo69JbKA=.e325aa0f-75e4-4811-863d-860a85a9bb3a@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <cQ1yj8jICgoS6Sl7hq-s3L3wKA5ZK9dUmMldo69JbKA=.e325aa0f-75e4-4811-863d-860a85a9bb3a@github.com>
Message-ID: <U-9-xTDYmRjeSPvlyLmjUAFT2mYQdQ10JlLOd8sDGS8=.2e1045b9-a248-40b6-bc24-7717f6703605@github.com>

On Tue, 9 Jan 2024 10:46:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 70:
>> 
>>> 68:             privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
>>> 69:                     WRITE_REPLACE_PARAM_TYPES, Object.class);
>>> 70:             privilegedCheckAccessibleMethod(cl, READ_RESOLVE_NAME,
>> 
>> Thinking ahead to when the security manager is removed, can the code that needs private access to field values (SUID) be more narrowly accessed? Perhaps switch to using a VarHandle and MethodHandles.Lookup. This may be a longer term issue and beyond the scope of this PR.
>> 
>> In the naming of the `PrivilegedXXX` methods, I would drop the "privileged" part of the name.
>> The methods do not change the privilege level and operate correctly if when the caller has the privileges needed. And all of these methods are read-only so there is no/little risk in their implementations and avoid refitting the terminology later.
>
> They are called `privilegedXXX` because they _are_ (already) privileged, not because they change the privileges.
> 
> But yes, in view of removing the security manager, the implementation could be more "modern". Will have a look.

> https://github.com/openjdk/jdk/pull/17129/commits/ff1b7068bd902f3030267afbc468e3244c944604

Thanks - that looks much cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447617134

From vklang at openjdk.org  Wed Jan 10 16:45:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Jan 2024 16:45:31 GMT
Subject: Integrated: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java
 still times out with ZGC, Generational ZGC, and SerialGC
In-Reply-To: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
References: <NwtHYlMvCqi8jbgz2Yv9EjgZTAktgQy3NKAfika1vjI=.b396ef7a-d009-45ef-bf5e-f8ca79410cb6@github.com>
Message-ID: <BW_N92sEDhE8G77C84Q840H1yyAOx8oL6kpeTF03x6U=.dea978cd-3756-4cdf-b6c2-8f9e2b4be7bb@github.com>

On Mon, 8 Jan 2024 21:13:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> As per conversation in the issue.

This pull request has now been integrated.

Changeset: b86c3b7a
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b86c3b7a68335d57699ea3c5ec6d09a62ea9026a
Stats:     8 lines in 3 files changed: 1 ins; 3 del; 4 mod

8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still times out with ZGC, Generational ZGC, and SerialGC

Reviewed-by: jpai, dholmes, alanb

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

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

From rriggs at openjdk.org  Wed Jan 10 16:52:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 16:52:26 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
Message-ID: <ESKiK251JihCIWGAGLedvBbGp2ykTAZ_oqZkYB9rUCw=.498c6447-4d80-4269-9a83-662add3e9b9a@github.com>

On Tue, 9 Jan 2024 10:41:31 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 53:
>> 
>>> 51:     private static final Class<?>[] READ_OBJECT_NO_DATA_PARAM_TYPES = {};
>>> 52:     private static final Class<?>[] WRITE_REPLACE_PARAM_TYPES = {};
>>> 53:     private static final Class<?>[] READ_RESOLVE_PARAM_TYPES = {};
>> 
>> These could share a single zero length Class<?> array.
>
> Conceptually, these are independent types. There's no logical relationship between them. Sharing a zero length array would convey a false sense of logical sharing.

true, but its wasted space and IMHO ok as a local and private implementation detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447655018

From eirbjo at openjdk.org  Wed Jan 10 17:04:29 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 17:04:29 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <Yk28MAUo0THuTa083uu-GCAVQiUiQ5RM7N_fXwsERQ4=.d6e51491-ca9a-40fb-b7aa-a8d98d762ec8@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <Yk28MAUo0THuTa083uu-GCAVQiUiQ5RM7N_fXwsERQ4=.d6e51491-ca9a-40fb-b7aa-a8d98d762ec8@github.com>
Message-ID: <s75cIa_CJBjOl0qhza78g4llQSruDnC9UURHoWP7HG4=.25aa8b0d-3f35-43c9-be1a-bd97853e8173@github.com>

On Mon, 8 Jan 2024 18:21:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Sounds like a CSR is needed for the behavioral change proposed here.

Thanks for flagging this @jddarcy 

I'm personally not 100% convinced a CSR is warranted in this case, but I'm of course happy to extend the following into a CSR if you or other reviewer think that's the best way forward:  

Let's review the intended and unintended behavioral changes in this PR:  

The _intended_ behavioral change is to extend the set of ZIP entries parsable by `ZipInputStream` to include "small Zip64 entries". Such entries meet the following criteria:
 
1. They are clearly marked as using the Zip64 format, meaning that the LOC's 'compressed size' and 'uncompressed size' fields are set to the "Zip64 magic value" 0xFFFFFFFF and that the LOC's extra field includes a valid _Zip64 Extended Information Field_.
2. They use _streaming mode_, meaning that the 'general purpose bit flag' 3 is set, that the Zip64 'Original Size' and 'Compressed Size' are both set to zero and that file data is followed by a 'Data Descriptor' containing the actual size values.
3. The Data Descriptor represents the 'compressed size' and 'uncompressed' size fields using 8 byte fields, instead of the regular 4 byte fields.

These entires are currently not parsable by `ZipInputStream`. Trying to parse them fails with an exception similar to the following:


java.util.zip.ZipException: invalid entry size (expected 0 but got 6 bytes)
	at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:616)


The _unintended_ behavioral change in this PR is that ZIP entries marked as Zip64, but still having a Data Descriptor using 4 bytes to represent the size fields will now become unparsable. Such entries meet critera 1 and 2 above, but not 3.

While I have not performed a corpus search, I believe such entries are rare, if they exist at all:

- They would be in clear violation of the `APPNOTE.txt` spec, which in 4.3.9.2 says  _ZIP64 format MAY be used regardless of the size of a file.  When extracting, if the zip64 extended information extra field is present for the file the compressed and uncompressed sizes will be 8 byte values_
- The `zipdetails` tool fails to parse such a file, instead reading the two 4-byte numbers into one 8-byte 'compressed size'
- The file cannot be parsed by external APIs similar to `ZipInputStream`, such as the Python `stream-unzip` module.

To avoid unintended behavioral changes in the implementation, care has been taken to make the Zip64 extra field validation code robust to invalid input, including out of bounds array access. 

To summarize, this PR aims to allow a set of useful, valid ZIP files to be parsed, at the cost of potentially making a small set of invalid ZIP files unparsable.

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

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

From rriggs at openjdk.org  Wed Jan 10 17:05:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 17:05:26 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v13]
In-Reply-To: <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>
Message-ID: <S93z1lsfaUWNRaBy6lHTXhkukX6pi1bhdd27qPIOeoM=.ae3187dd-f702-422c-a103-b212f810d9e6@github.com>

On Wed, 10 Jan 2024 15:43:46 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 reviewers feedback.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 129:

> 127:         Object spf = objectFromStatic(f);
> 128:         if (spf == null) {
> 129:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME + " must be non-null");

"must" -> "should".

The [serialization spec](https://docs.oracle.com/en/java/javase/21/docs/specs/serialization/serial-arch.html#defining-serializable-fields-for-a-class) describes the behavior if the field is null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447662278

From rriggs at openjdk.org  Wed Jan 10 17:05:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 17:05:29 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: <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>

On Tue, 19 Dec 2023 15:58:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> 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.

The spec is silent about methods being 'native'; it would generally be impractical to implement native methods for these purposes, but a native method can implement the behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447665831

From wxiao at openjdk.org  Wed Jan 10 17:07:31 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:07:31 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
Message-ID: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>

Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
It is a clean backport.

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

Commit messages:
 - Backport 8ae309ebacd6947bbad2ef168ca13702e1cba099

Changes: https://git.openjdk.org/jdk22/pull/55/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=55&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318971
  Stats: 86 lines in 2 files changed: 84 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk22/pull/55.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/55/head:pull/55

PR: https://git.openjdk.org/jdk22/pull/55

From alanb at openjdk.org  Wed Jan 10 17:21:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 17:21:24 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <hi-ESBm_4Bxe_sW6TmhHISxK2rGZoYdSGbubk4kMn1Q=.b6eebef3-8f8c-4b59-a1cc-53a96e5cd45f@github.com>

On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While this might not fix 8314515, it should at least make it more exact.

test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 42:

> 40:     private static void testFairness(boolean fair,
> 41:                                      final SynchronousQueue<Integer> q,
> 42:                                      final VarHandle underlyingHandle)

The updated approach to wait until the thread is finished putting seems okay. It might be a bit cleaner for the param to testFariness be the underlying LTQ rather than calling it with a VarHandle, meaning do this in the caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17082#discussion_r1447689444

From rgiulietti at openjdk.org  Wed Jan 10 17:25:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 17:25:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v12]
In-Reply-To: <ESKiK251JihCIWGAGLedvBbGp2ykTAZ_oqZkYB9rUCw=.498c6447-4d80-4269-9a83-662add3e9b9a@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <UBUlv4UaOdPFODfd_ifXlL2qR34tWLa6GY5sPgAxRB8=.6a1e8445-abd4-4883-b09e-f6ca1277dd6c@github.com>
 <9n95aB0OWlmTzde0I7mg0zJoJaCdBPPW7ZOx-VlmkJU=.fcc99b72-e261-4f0b-8d67-f2f734dffd22@github.com>
 <vrjEuYtNuPPR_SUic_fvpjvcPEDSfQcZ-8PqP2g8wMU=.d44e7b32-7381-4813-9c78-0e8455f40bae@github.com>
 <ESKiK251JihCIWGAGLedvBbGp2ykTAZ_oqZkYB9rUCw=.498c6447-4d80-4269-9a83-662add3e9b9a@github.com>
Message-ID: <ZQN6hXiJF2tQ2Bjo3Z7DEFbmlHqp0Y67fnqKozD6EdQ=.4d6780ef-1539-485f-96ba-16ea4ec4947a@github.com>

On Wed, 10 Jan 2024 16:49:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Conceptually, these are independent types. There's no logical relationship between them. Sharing a zero length array would convey a false sense of logical sharing.
>
> true, but its wasted space and IMHO ok as a local and private implementation detail.

I agree that, as a private implementation detail, this can be optimized by sharing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447693340

From rgiulietti at openjdk.org  Wed Jan 10 17:33:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 17:33:29 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v13]
In-Reply-To: <S93z1lsfaUWNRaBy6lHTXhkukX6pi1bhdd27qPIOeoM=.ae3187dd-f702-422c-a103-b212f810d9e6@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <N2GT5zDSfyYh85OzZFJsFvhVdDcQxB-UsWu1LJMxanI=.34972882-cf4a-4ca2-892f-6b4c4ceb3594@github.com>
 <S93z1lsfaUWNRaBy6lHTXhkukX6pi1bhdd27qPIOeoM=.ae3187dd-f702-422c-a103-b212f810d9e6@github.com>
Message-ID: <AXvTBEAOalIZOy4Kk39NdtAvWrIz7vSBMojjInvMu2E=.20642795-b3a7-428f-b799-c81a3905b7c9@github.com>

On Wed, 10 Jan 2024 16:55:58 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 reviewers feedback.
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 129:
> 
>> 127:         Object spf = objectFromStatic(f);
>> 128:         if (spf == null) {
>> 129:             commitEvent(cl, SERIAL_PERSISTENT_FIELDS_NAME + " must be non-null");
> 
> "must" -> "should".
> 
> The [serialization spec](https://docs.oracle.com/en/java/javase/21/docs/specs/serialization/serial-arch.html#defining-serializable-fields-for-a-class) describes the behavior if the field is null.

Right

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447705388

From naoto at openjdk.org  Wed Jan 10 17:36:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 17:36:27 GMT
Subject: [jdk22] Integrated: 8320919: Clarify Locale related system properties
In-Reply-To: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
References: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
Message-ID: <UKVAatTvKdKoeKoyucQekSnW460pzudhe6gFeC2LDXM=.88681b32-e1af-401c-9838-29abb7ea9e5d@github.com>

On Tue, 9 Jan 2024 23:55:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document clarification to JDK22

This pull request has now been integrated.

Changeset: 46b1b1ae
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/46b1b1ae8ddc9466bda5af5ba2e917ded3352f4d
Stats:     81 lines in 1 file changed: 71 ins; 0 del; 10 mod

8320919: Clarify Locale related system properties

Reviewed-by: iris
Backport-of: 376051a9be95e0e4acf3c59d0eba3e9ef8727d79

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

PR: https://git.openjdk.org/jdk22/pull/47

From lancea at openjdk.org  Wed Jan 10 17:41:26 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 10 Jan 2024 17:41:26 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
Message-ID: <BdHkK1Eo9Co0zSDnRfB1fm63QWdR4Ky6-TkEWbIsQqw=.8ab951f2-2de3-43d4-8f54-3e4d4d3d60e3@github.com>

On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
>> 
>> 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)
>
> Eirik Bj?rsn?s has updated the pull request with a new target base 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:
> 
>  - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime.
>  - Merge branch 'master' into zipfs-preserve-external-file-attrs
>  - Preserve non-permission 'external file attributes' bits when setting posix permissions

Thank you for the PR.  Overall it looks good a few couple nit comments.

Extra credit to convert this from testng to a junit test but not a must

test/jdk/jdk/nio/zipfs/TestPosix.java line 761:

> 759:         Files.write(zipFile, zip);
> 760: 
> 761:         // Verify that a read/synch roundtrip preserves the external file attributes

typo 'synch'

test/jdk/jdk/nio/zipfs/TestPosix.java line 770:

> 768: 
> 769:         // Verify calling Files.setPosixFilePermissions with current permission set
> 770:         try (FileSystem fs = FileSystems.newFileSystem(zipFile, ENV_POSIX)) {

This should be a separate test IMHO

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17170#pullrequestreview-1813747144
PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447701846
PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447718468

From rgiulietti at openjdk.org  Wed Jan 10 17:45:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 17:45:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@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>
 <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>
Message-ID: <-_PvRm5zjQX1rUk3bW0CEiKJWChU0-UTcOPUhOyc2qk=.15e65620-889b-49fe-a18e-35dbde1ade39@github.com>

On Wed, 10 Jan 2024 16:58:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'm not sure that a `native` method is not considered effective by serialization. I have to check.
>
> The spec is silent about methods being 'native'; it would generally be impractical to implement native methods for these purposes, but a native method can implement the behavior.

@RogerRiggs The checks are agnostic about a method being `native` or not, so I'm not sure I get your point about `native` methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447721944

From wxiao at openjdk.org  Wed Jan 10 17:48:30 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:48:30 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
Message-ID: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>

Better Error Handling for Jar Tool When Processing Non-existent Files. <br>

It needs to be backported to JDK22.

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

Commit messages:
 - Backport 8ae309ebacd6947bbad2ef168ca13702e1cba099

Changes: https://git.openjdk.org/jdk22/pull/56/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=56&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318971
  Stats: 86 lines in 2 files changed: 84 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk22/pull/56.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/56/head:pull/56

PR: https://git.openjdk.org/jdk22/pull/56

From wxiao at openjdk.org  Wed Jan 10 17:49:25 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:49:25 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
References: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
Message-ID: <avU6U_TpsH21nXELI7l_4cozCKhM-8wIw__jRnWW0qw=.0eed0aa3-75ac-4675-ab9c-358c2176e200@github.com>

On Wed, 10 Jan 2024 17:02:03 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> It is a clean backport.

Use this PR instead https://github.com/openjdk/jdk22/pull/56.

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

PR Comment: https://git.openjdk.org/jdk22/pull/55#issuecomment-1885333004

From wxiao at openjdk.org  Wed Jan 10 17:49:26 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 10 Jan 2024 17:49:26 GMT
Subject: [jdk22] Withdrawn: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
References: <-LODLKFRtovbU3hGJ__1m-GeaP-BDWxtZTUXqIzQ0EQ=.e9469bce-b68d-42d7-adc6-6490603b2548@github.com>
Message-ID: <ptqyOlhc28L4kXBNqCIBLRk4_l3wzwAsQjV7Z6Rw4PQ=.e290d458-3703-43ab-a28b-fbaab5366fb3@github.com>

On Wed, 10 Jan 2024 17:02:03 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> It is a clean backport.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk22/pull/55

From vklang at openjdk.org  Wed Jan 10 17:50:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Jan 2024 17:50:23 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <hi-ESBm_4Bxe_sW6TmhHISxK2rGZoYdSGbubk4kMn1Q=.b6eebef3-8f8c-4b59-a1cc-53a96e5cd45f@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
 <hi-ESBm_4Bxe_sW6TmhHISxK2rGZoYdSGbubk4kMn1Q=.b6eebef3-8f8c-4b59-a1cc-53a96e5cd45f@github.com>
Message-ID: <leMtDWennn2cBFkFov25M4Q2vWihrYdWqXwb2nVsjoY=.f717c65e-61fc-4d51-a080-beb8e00543dd@github.com>

On Wed, 10 Jan 2024 17:18:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> While this might not fix 8314515, it should at least make it more exact.
>
> test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 42:
> 
>> 40:     private static void testFairness(boolean fair,
>> 41:                                      final SynchronousQueue<Integer> q,
>> 42:                                      final VarHandle underlyingHandle)
> 
> The updated approach to wait until the thread is finished putting seems okay. It might be a bit cleaner for the param to testFariness be the underlying LTQ rather than calling it with a VarHandle, meaning do this in the caller.

I tried that first, but since the SynchronousQueue needs to be the one interfaced with it means passing in a SynchronousQueue and a LinkedTransferQueue pair where there is a silent dependency between the two (the LTQ needs to be the Transferer of the SynchronousQueue) so I found it safer, and more straightforward to obtain it in testFairness.

What might make it cleaner still, would be to move the creation of the MH to a static and not pass that in as an argument, so I'll do that instead. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17082#discussion_r1447727942

From jvernee at openjdk.org  Wed Jan 10 18:00:30 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Jan 2024 18:00:30 GMT
Subject: [jdk22] RFR: 8322324: java/foreign/TestStubAllocFailure.java times out
 while waiting for forked process
Message-ID: <rHVeex3NSElclhVhKGYga0pfQUCycGqFkR4mizrY6Cc=.619c98f8-df51-4029-a610-8804514c595f@github.com>

Hi all,

This pull request contains a backport of commit [d2d58dd6](https://github.com/openjdk/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jorn Vernee on 10 Jan 2024 and was reviewed by Maurizio Cimadamore.

This is a P2 test only change, and we are currently in Ramp Down Phase 1. The release process allows P1-P5 test-only changes during RDP1: https://openjdk.org/jeps/3#Quick-reference

Thanks!

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

Commit messages:
 - Backport d2d58dd6a8ec366a4bc3eb12a253b252de24557e

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

PR: https://git.openjdk.org/jdk22/pull/52

From vklang at openjdk.org  Wed Jan 10 18:03:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Jan 2024 18:03:32 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0" [v2]
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <frm7iqwuvS3BN9ljqKt3OnUOWZDWN6Y9NiLN83yNXzU=.54eba6e5-7169-4975-835c-a03d786423a7@github.com>

> While this might not fix 8314515, it should at least make it more exact.

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Cleaning up Fairness.java:s underlying queue implementation access
 - Improving SynchronousQueue Fairness test to only proceed once observing that the previous thread is enqueued as a producer

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

Changes: https://git.openjdk.org/jdk/pull/17082/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17082&range=01
  Stats: 35 lines in 1 file changed: 28 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17082/head:pull/17082

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

From vklang at openjdk.org  Wed Jan 10 18:03:34 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Jan 2024 18:03:34 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0" [v2]
In-Reply-To: <frm7iqwuvS3BN9ljqKt3OnUOWZDWN6Y9NiLN83yNXzU=.54eba6e5-7169-4975-835c-a03d786423a7@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
 <frm7iqwuvS3BN9ljqKt3OnUOWZDWN6Y9NiLN83yNXzU=.54eba6e5-7169-4975-835c-a03d786423a7@github.com>
Message-ID: <pDOBt7V9W22V17VNqAe5xW1st0ksWxofgzD2Boekx5I=.cb474121-c2bf-48ca-8b1d-f4b62de80d76@github.com>

On Wed, 10 Jan 2024 18:01:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> While this might not fix 8314515, it should at least make it more exact.
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Cleaning up Fairness.java:s underlying queue implementation access
>  - Improving SynchronousQueue Fairness test to only proceed once observing that the previous thread is enqueued as a producer

test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 101:

> 99:         testFairness(false, new SynchronousQueue<>());
> 100:         testFairness(false, new SynchronousQueue<>(false));
> 101:         testFairness(true,  new SynchronousQueue<>(true));

@AlanBateman Better? :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17082#discussion_r1447741829

From eirbjo at openjdk.org  Wed Jan 10 18:11:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 18:11:37 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v3]
In-Reply-To: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
Message-ID: <Zu-0F4RWBZ0egEyzAzcSY3NHquXX_148vfF4TIty62M=.8d9139a3-711a-451f-9071-921ea46b16a9@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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
> 
> 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)

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Extract testing of the Files.setPosixFilePermissions operation and the Files.setLastModifiedTime operation into separate test methods.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17170/files
  - new: https://git.openjdk.org/jdk/pull/17170/files/524159f3..e4a505fa

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

  Stats: 53 lines in 1 file changed: 35 ins; 11 del; 7 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 eirbjo at openjdk.org  Wed Jan 10 18:11:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 18:11:40 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <BdHkK1Eo9Co0zSDnRfB1fm63QWdR4Ky6-TkEWbIsQqw=.8ab951f2-2de3-43d4-8f54-3e4d4d3d60e3@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
 <BdHkK1Eo9Co0zSDnRfB1fm63QWdR4Ky6-TkEWbIsQqw=.8ab951f2-2de3-43d4-8f54-3e4d4d3d60e3@github.com>
Message-ID: <bbS1KTOpu1AwyMXmmftuJwtQMQXKq3zpiUao9UOSRag=.0d29f836-c4f2-490a-88cf-052d1087ba61@github.com>

On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Thank you for the PR. Overall it looks good a few couple nit comments.

Thanks Lance, see e4a505fa073874824f247c20b76c3531a068ee32 for the latest update following your review.

> test/jdk/jdk/nio/zipfs/TestPosix.java line 761:
> 
>> 759:         Files.write(zipFile, zip);
>> 760: 
>> 761:         // Verify that a read/synch roundtrip preserves the external file attributes
> 
> typo 'synch'

This comment was replaced with "Run the provided action on the ZipFileSystem" following the rewrite described below.

> test/jdk/jdk/nio/zipfs/TestPosix.java line 770:
> 
>> 768: 
>> 769:         // Verify calling Files.setPosixFilePermissions with current permission set
>> 770:         try (FileSystem fs = FileSystems.newFileSystem(zipFile, ENV_POSIX)) {
> 
> This should be a separate test IMHO

I've separated two tests `setPermissionsShouldPreserveRemainingBits` and `setLastModifiedTimeShouldNotChangeExternalFileAttribute`, both using the support method `assertExternalFileAttributeUnchanged`.

I agree this was much cleaner, since these are in fact separate and independent (but perhaps overlapping) issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1885367252
PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447745607
PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447747366

From darcy at openjdk.org  Wed Jan 10 18:16:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Jan 2024 18:16:05 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v7]
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <j-uG3rOtKjMBlJ4bg7lJg0fFeVGmkWJBsNqMXJ8YGMI=.ea6a42d0-6341-47db-b4aa-c38f53771ed8@github.com>

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

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

 - Adjust JLS quote and update copyright.
 - Merge branch 'master' into JDK-8322878
 - Expand test cases.
 - Update spec; test sealed class structures.
 - Improve regression test.
 - Update non-sealed computation.
 - Add non-seal'ing support.
 - JDK-8322878: Including sealing information Class.toGenericString()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17239/files
  - new: https://git.openjdk.org/jdk/pull/17239/files/d5a451d0..4cfc4e3d

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

  Stats: 17609 lines in 565 files changed: 12491 ins; 2504 del; 2614 mod
  Patch: https://git.openjdk.org/jdk/pull/17239.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17239/head:pull/17239

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

From forax at univ-mlv.fr  Wed Jan 10 18:16:55 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 10 Jan 2024 19:16:55 +0100 (CET)
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <MW4PR10MB5774AA5CEDA7B1FEFDA4D07BFF692@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <MW4PR10MB5774AA5CEDA7B1FEFDA4D07BFF692@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <509230836.99178022.1704910615048.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "David Alayachew" <davidalayachew at gmail.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Wednesday, January 10, 2024 2:33:45 PM
> Subject: Re: Gatherers -- conditionalWindowFixed?

> Hi David!

> Apologies for the late reply, there's been lots of catching up to do after the
> holidays.

> >I'm really excited for what this will enable for us.

> I'm really glad to hear that \uD83D\uDE42

> >It is very much appreciated.

> \uD83D\uDC4D

>> Could we add one more method for a conditionalWindowFixed? We would need to pass
>> in some Predicate<T>. If the predicate returns true, create a list (if it does
>> not already exist) then add the element to it. If the predicate returns false
>> while the list is empty, then just move along to the next. Else if the
>> predicate returns false while the list is non empty, pass the list down into
> > the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

> What ends up under Gatherers.* does require careful triaging, ideally by first
> seeing user-created implementations being heavily used/useful, then potential
> candidate for Gatherers.*, and then at the end it might end up in Stream as a
> dedicated method.

> By virtue of the Gatherers API, it seems pretty straight-forward for you to
> implement what you describe, and personally I'd probably call it something like
> windowBy .

> Just typing this up as I write this reply, it could look something like this:

> <TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR> includeInCurrentWindow) {
> class State {
> ArrayList<TR> window;

> boolean integrate(TR element, Gatherer.Downstream<? super List<TR>> downstream)
> {
> if (window != null && !includeInCurrentWindow.test(element)) {
> var result = Collections.unmodifiableList(window);
> window = null;
> if (!downstream.push(result))
> return false;
> }

> if (window == null)
> window = new ArrayList<>();
> return window.add(element);
> }

> void finish(Gatherer.Downstream<? super List<TR>> downstream) {
> if (window != null) {
> var result = Collections.unmodifiableList(window);
> window = null;
> downstream.push(result);
> }
> }
> }
> return Gatherer.<TR, State, List<TR>>ofSequential(State::new, State::integrate,
> State::finish);
> }

> jshell> Stream.of("header", "value1", "value2", "header", "header", "value 3",
> "value 4", null).gather(windowBy(Predicate.not("header"::equals))).toList()
> $1 ==> [[header, value1, value2], [header], [header, value 3, value 4, null]]

Hello, 
I've two questions, 
1/ Is there a reason why the integrator is not declared greedy (I'm still not sure to what exactly Greedy means in the context of gatherers) ? 
2/ Is there a reason to write the code in a OOP way like you have done instead of only having fields in State and specify the behaviors using lambdas (because with lambdas will you get inference) 

<T> Gatherer<T, ?, List<T>> windowBy(Predicate<? super T> includeInCurrentWindow) { 
class State { 
ArrayList<T> window; 
} 
return Gatherer.ofSequential( 
State::new, 
(state, element, downstream) -> { 
... 
}, 
(state, downstream) -> { 
... 
}); 
} 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> Sent: Wednesday, 10 January 2024 07:05
> To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> Subject: Gatherers -- conditionalWindowFixed?
> Hello Core Libs Dev Team,

> I have been reading through JEP 461 ( [ https://openjdk.org/jeps/461 |
> https://openjdk.org/jeps/461 ] ) about Gatherers, and I'm really excited for
> what this will enable for us.

> By far, the most important functionality that this API facilitates is the
> ability to create windows. Anytime I needed a window, I was basically forced to
> use a for loop. Now, the 2 most common window cases are being handed to us for
> free. It is very much appreciated.

> Could we add one more method for a conditionalWindowFixed? We would need to pass
> in some Predicate<T>. If the predicate returns true, create a list (if it does
> not already exist) then add the element to it. If the predicate returns false
> while the list is empty, then just move along to the next. Else if the
> predicate returns false while the list is non empty, pass the list down into
> the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

> The reason I think this is worth adding is because it facilitates a really
> common use case. We may not want all windows to be the same size.

> Is this something worth adding to the Gatherers API?

> Thank you for your time and help!
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/311cafc8/attachment.htm>

From mchung at openjdk.org  Wed Jan 10 18:17:32 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 10 Jan 2024 18:17:32 GMT
Subject: [jdk22] Integrated: 8322809: SystemModulesMap::classNames and
 moduleNames arrays do not match the order
In-Reply-To: <A8bIBR9I_FngBg7MUvF5w16niv6i-OzTNflY0S2uZD0=.fa0668fd-6ec5-4600-b502-cf700ad10d8f@github.com>
References: <A8bIBR9I_FngBg7MUvF5w16niv6i-OzTNflY0S2uZD0=.fa0668fd-6ec5-4600-b502-cf700ad10d8f@github.com>
Message-ID: <gCMelt9uN9dTgv1rcmhhrU5D7VZk2BgumJbVoriD7XE=.45705207-e89d-4df5-aaba-8a35c280cda3@github.com>

On Tue, 9 Jan 2024 22:16:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This pull request contains a backport of commit [f3be138e](https://github.com/openjdk/jdk/commit/f3be138eb80c9e7f6cc21afb75cda9e49b667c8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 9 Jan 2024 and was reviewed by Alan Bateman.

This pull request has now been integrated.

Changeset: 71cc879b
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/71cc879bd46ece4979e7beaed5461d373bdb196f
Stats:     290 lines in 6 files changed: 282 ins; 0 del; 8 mod

8322809: SystemModulesMap::classNames and moduleNames arrays do not match the order

Reviewed-by: alanb
Backport-of: f3be138eb80c9e7f6cc21afb75cda9e49b667c8a

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

PR: https://git.openjdk.org/jdk22/pull/46

From sspitsyn at openjdk.org  Wed Jan 10 18:19:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 18:19:30 GMT
Subject: [jdk22] Integrated: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <vWZGC3_rp__dEhj52NGzKfdnbmev6XfHp2b18sagmCA=.ab386b0c-b8d8-4d4c-a203-bcd59b076f96@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 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!

This pull request has now been integrated.

Changeset: 865cf888
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/865cf888efbdf5533ded8ca39ef706de9b48dc15
Stats:     229 lines in 15 files changed: 196 ins; 0 del; 33 mod

8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

Reviewed-by: alanb
Backport-of: 0f8e4e0a81257c678e948c341a241dc0b810494f

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

PR: https://git.openjdk.org/jdk22/pull/23

From eirbjo at openjdk.org  Wed Jan 10 18:29:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 18:29:40 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v4]
In-Reply-To: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
Message-ID: <v76JlFNBZXCRcfJVhrngkQ7Oyz07dSFGCLrES08coT4=.f4053000-02ef-4432-84f7-652c30f34035@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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
> 
> 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)

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Convert TestPosix.java from testng to Junit 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17170/files
  - new: https://git.openjdk.org/jdk/pull/17170/files/e4a505fa..885871f8

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

  Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 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 eirbjo at openjdk.org  Wed Jan 10 18:29:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 18:29:41 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v2]
In-Reply-To: <BdHkK1Eo9Co0zSDnRfB1fm63QWdR4Ky6-TkEWbIsQqw=.8ab951f2-2de3-43d4-8f54-3e4d4d3d60e3@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <DFfSb12nNtqjjRUANdD-fb3s3hgKZoaplbcT-p7mebM=.1047c45a-c21e-4384-bdc2-2864551eb78d@github.com>
 <BdHkK1Eo9Co0zSDnRfB1fm63QWdR4Ky6-TkEWbIsQqw=.8ab951f2-2de3-43d4-8f54-3e4d4d3d60e3@github.com>
Message-ID: <jfcsxH9yDOOvrMMIQZSmf9i1Rlu8GfAz7E3hrX5xswM=.8e98cd1d-8e06-4a38-9778-f89656a2b8fb@github.com>

On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Extra credit to convert this from testng to a junit test but not a must

Challenge accepted, see 885871f for the conversion to JUnit 5.

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

PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1885395478

From prappo at openjdk.org  Wed Jan 10 18:30:26 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 10 Jan 2024 18:30:26 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v7]
In-Reply-To: <j-uG3rOtKjMBlJ4bg7lJg0fFeVGmkWJBsNqMXJ8YGMI=.ea6a42d0-6341-47db-b4aa-c38f53771ed8@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <j-uG3rOtKjMBlJ4bg7lJg0fFeVGmkWJBsNqMXJ8YGMI=.ea6a42d0-6341-47db-b4aa-c38f53771ed8@github.com>
Message-ID: <U1eKnH8Cc8tqyg7j54KlgZ3hfgIjhdmykNFDs50U9cI=.c1a1d861-0770-405c-902a-677c3edd75cf@github.com>

On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
>> 
>> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Adjust JLS quote and update copyright.
>  - Merge branch 'master' into JDK-8322878
>  - Expand test cases.
>  - Update spec; test sealed class structures.
>  - Improve regression test.
>  - Update non-sealed computation.
>  - Add non-seal'ing support.
>  - JDK-8322878: Including sealing information Class.toGenericString()

> /contributor add @pavelrappo

Thanks, Joe. Making me an "overriding author" was a bit over the top. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/17239#issuecomment-1885397723

From mcimadamore at openjdk.org  Wed Jan 10 18:34:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 18:34:23 GMT
Subject: [jdk22] RFR: 8322324: java/foreign/TestStubAllocFailure.java times
 out while waiting for forked process
In-Reply-To: <rHVeex3NSElclhVhKGYga0pfQUCycGqFkR4mizrY6Cc=.619c98f8-df51-4029-a610-8804514c595f@github.com>
References: <rHVeex3NSElclhVhKGYga0pfQUCycGqFkR4mizrY6Cc=.619c98f8-df51-4029-a610-8804514c595f@github.com>
Message-ID: <4fT0pXV8Zwt9-Jq3mY2-DaWDTxLX2C0d5pw6Q_02D-o=.509e3606-2c14-4b08-9351-4c441bf1a6ed@github.com>

On Wed, 10 Jan 2024 13:18:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d2d58dd6](https://github.com/openjdk/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 10 Jan 2024 and was reviewed by Maurizio Cimadamore.
> 
> This is a P2 test only change, and we are currently in Ramp Down Phase 1. The release process allows P1-P5 test-only changes during RDP1: https://openjdk.org/jeps/3#Quick-reference
> 
> Thanks!

Looks good (already approved in mainline)

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/52#pullrequestreview-1813861066

From rriggs at openjdk.org  Wed Jan 10 18:39:25 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 18:39:25 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v7]
In-Reply-To: <j-uG3rOtKjMBlJ4bg7lJg0fFeVGmkWJBsNqMXJ8YGMI=.ea6a42d0-6341-47db-b4aa-c38f53771ed8@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <j-uG3rOtKjMBlJ4bg7lJg0fFeVGmkWJBsNqMXJ8YGMI=.ea6a42d0-6341-47db-b4aa-c38f53771ed8@github.com>
Message-ID: <c1XlLen2c6ceAiyo7ZhIZ5tZ6fftHItECEtM70pAkq4=.cd0f9018-3e71-4303-9de2-6a563da67cce@github.com>

On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
>> 
>> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Adjust JLS quote and update copyright.
>  - Merge branch 'master' into JDK-8322878
>  - Expand test cases.
>  - Update spec; test sealed class structures.
>  - Improve regression test.
>  - Update non-sealed computation.
>  - Add non-seal'ing support.
>  - JDK-8322878: Including sealing information Class.toGenericString()

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17239#pullrequestreview-1813866824

From darcy at openjdk.org  Wed Jan 10 18:39:27 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Jan 2024 18:39:27 GMT
Subject: RFR: JDK-8322878: Including sealing information
 Class.toGenericString() [v7]
In-Reply-To: <U1eKnH8Cc8tqyg7j54KlgZ3hfgIjhdmykNFDs50U9cI=.c1a1d861-0770-405c-902a-677c3edd75cf@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
 <j-uG3rOtKjMBlJ4bg7lJg0fFeVGmkWJBsNqMXJ8YGMI=.ea6a42d0-6341-47db-b4aa-c38f53771ed8@github.com>
 <U1eKnH8Cc8tqyg7j54KlgZ3hfgIjhdmykNFDs50U9cI=.c1a1d861-0770-405c-902a-677c3edd75cf@github.com>
Message-ID: <I5ttrU247qCJ2ooQ-F03VR0t6CPoAIr3e0l6hncWh14=.9de0c810-1802-4325-afce-13ac86b356b9@github.com>

On Wed, 10 Jan 2024 18:27:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > /contributor add @pavelrappo
> 
> Thanks, Joe. Making me an "overriding author" was a bit over the top. :)

Skimmed the docs too quickly when looking for a "co-author" command :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17239#issuecomment-1885410390

From rriggs at openjdk.org  Wed Jan 10 18:44:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 18:44:27 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <-_PvRm5zjQX1rUk3bW0CEiKJWChU0-UTcOPUhOyc2qk=.15e65620-889b-49fe-a18e-35dbde1ade39@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>
 <P61NtoHoVCkgTzsE1rBwnka1HA7Vjx_LJkXmoV-LOJo=.81a2b1aa-5666-4b25-9966-366ab64bb7fe@github.com>
 <-_PvRm5zjQX1rUk3bW0CEiKJWChU0-UTcOPUhOyc2qk=.15e65620-889b-49fe-a18e-35dbde1ade39@github.com>
Message-ID: <yYu2NIELm2LdfDtuaqRPhoSH55_7Au8GZxePmE2xbuc=.9489a6b0-7740-4ead-a4d7-801fae95f45b@github.com>

On Wed, 10 Jan 2024 17:41:41 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The spec is silent about methods being 'native'; it would generally be impractical to implement native methods for these purposes, but a native method can implement the behavior.
>
> @RogerRiggs The checks are agnostic about a method being `native` or not, so I'm not sure I get your point about `native` methods.

Right, there's nothing to change; a method declared as native is not mis-declared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1447785756

From darcy at openjdk.org  Wed Jan 10 18:49:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Jan 2024 18:49:30 GMT
Subject: Integrated: JDK-8322878: Including sealing information
 Class.toGenericString()
In-Reply-To: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
References: <8wPP-f_aNp8ijVsktWRIwxbVvcWTP7nbkMTal1qNYXA=.282fcceb-636a-4984-b72c-fa55fc0272f5@github.com>
Message-ID: <QvcAHd3XPLy2ZTbGKx6DyzAY62abgx92PowpbhScvsw=.5d8a4d02-0a56-49b2-8cc5-7fd419e869bf@github.com>

On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled.
> 
> This is the initial spec, implementation, and test updated needed for that change. If there is consensus this is a reasonable direction, I'll create the CSR, etc.

This pull request has now been integrated.

Changeset: 525063be
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/525063be90bc67257e5d9301a4270179c03ada9d
Stats:     206 lines in 2 files changed: 186 ins; 1 del; 19 mod

8322878: Including sealing information Class.toGenericString()

Co-authored-by: Pavel Rappo <prappo at openjdk.org>
Reviewed-by: rriggs

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

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

From darcy at openjdk.org  Wed Jan 10 18:55:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Jan 2024 18:55:43 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier [v2]
In-Reply-To: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
Message-ID: <xJ1yvyerga8fMqf43yCh8Sp_jpAwooW6m5XrO303nrk=.fb133e38-83d8-48af-9f22-f05fa1c5047d@github.com>

> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

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

  Implement review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17338/files
  - new: https://git.openjdk.org/jdk/pull/17338/files/d96a2965..e5816889

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

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

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

From naoto at openjdk.org  Wed Jan 10 18:56:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 18:56:38 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v3]
In-Reply-To: <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
Message-ID: <DC0FVU3kM_ZT-MdKJReQoFcSVm_ZtEIsCm5kIWIttLg=.3d3e68c7-feae-426e-b716-c90db56cc7dd@github.com>

On Tue, 9 Jan 2024 23:40:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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 18 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8320788-system.getProperties
>  - Reflects review comments
>  - initial commit
>  - 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>
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/376051a9...7444bb51

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17317#issuecomment-1885433436

From naoto at openjdk.org  Wed Jan 10 18:56:40 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 18:56:40 GMT
Subject: Integrated: 8320788: The system properties page is missing some
 properties
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <SfY9Yh4d3HI8o2gEQmSPjcAkZi061rRil4P7ASbCPpA=.fe694a35-ae78-4387-b30c-7d66108b5301@github.com>

On Tue, 9 Jan 2024 00:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.

This pull request has now been integrated.

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

8320788: The system properties page is missing some properties

Reviewed-by: iris, rriggs, bpb, joehw

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

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

From rgiulietti at openjdk.org  Wed Jan 10 18:56:45 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 10 Jan 2024 18:56:45 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v14]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>

> Adds serialization misdeclaration events to JFR.

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

  Small space optimization.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/ff1b7068..b76285d9

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

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 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 jbhateja at openjdk.org  Wed Jan 10 19:20:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 Jan 2024 19:20:26 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
Message-ID: <cTrBEvD0fasY-dHJSCSBegV3tZmihQTjDuUcDhrEWJ4=.7d2488ff-5709-437b-b4a5-3504b4d5ac29@github.com>

On Tue, 9 Jan 2024 16:48:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using emulated variable blend E-Core optimized instruction.

Following are the performance numbers for existing Vector API JMH micro benchmark over Meteor Lake - Crestmont E-cores.
![image](https://github.com/openjdk/jdk/assets/59989778/dab762f8-2379-4fcf-90da-f765e907c6c1)

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

PR Comment: https://git.openjdk.org/jdk/pull/17261#issuecomment-1885525420

From viktor.klang at oracle.com  Wed Jan 10 19:29:45 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 10 Jan 2024 19:29:45 +0000
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <509230836.99178022.1704910615048.JavaMail.zimbra@univ-eiffel.fr>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <MW4PR10MB5774AA5CEDA7B1FEFDA4D07BFF692@MW4PR10MB5774.namprd10.prod.outlook.com>
 <509230836.99178022.1704910615048.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774D2C27CF509EE48B8DC66FF692@MW4PR10MB5774.namprd10.prod.outlook.com>

>1/ Is there a reason why the integrator is not declared greedy (I'm still not sure to what exactly Greedy means in the context of gatherers) ?

No, that was just a (benign) omission from typing the solution as I was typing the email ?

>2/ Is there a reason to write the code in a OOP way like you have done instead of only having fields in State and specify the behaviors using lambdas (because with lambdas will you get inference)

Great question!
I chose to do that since I wanted to A) allocate the backing list on-demand, and also B) not allocate a new ArrayList for the downstream windows and retain the (cleared) old one (since its size could become needlessly large).


As a side-note, I tend to prototype using lambdas and then refactor as/when needed to either embed logic in the state or even migrate into a full-on implementation of the Gatherer interface (for instance if I want to override composition).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


________________________________
From: Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 10 January 2024 19:16
To: Viktor Klang <viktor.klang at oracle.com>
Cc: David Alayachew <davidalayachew at gmail.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Re: Gatherers -- conditionalWindowFixed?



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "David Alayachew" <davidalayachew at gmail.com>, "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Wednesday, January 10, 2024 2:33:45 PM
Subject: Re: Gatherers -- conditionalWindowFixed?
Hi David!

Apologies for the late reply, there's been lots of catching up to do after the holidays.

>I'm really excited for what this will enable for us.

I'm really glad to hear that \uD83D\uDE42

>It is very much appreciated.

\uD83D\uDC4D

> Could we add one more method for a conditionalWindowFixed? We would need to pass in some Predicate<T>. If the predicate returns true, create a list (if it does not already exist) then add the element to it. If the predicate returns false while the list is empty, then just move along to the next. Else if the predicate returns false while the list is non empty, pass the list down into the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

What ends up under Gatherers.* does require careful triaging, ideally by first seeing user-created implementations being heavily used/useful, then potential candidate for Gatherers.*, and then at the end it might end up in Stream as a dedicated method.

By virtue of the Gatherers API, it seems pretty straight-forward for you to implement what you describe, and personally I'd probably call it something like windowBy.

Just typing this up as I write this reply, it could look something like this:

<TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR> includeInCurrentWindow) {
  class State {
    ArrayList<TR> window;

    boolean integrate(TR element, Gatherer.Downstream<? super List<TR>> downstream) {
      if (window != null && !includeInCurrentWindow.test(element)) {
        var result = Collections.unmodifiableList(window);
        window = null;
        if (!downstream.push(result))
          return false;
      }

      if (window == null)
        window = new ArrayList<>();

      return window.add(element);
    }

    void finish(Gatherer.Downstream<? super List<TR>> downstream) {
      if (window != null) {
        var result = Collections.unmodifiableList(window);
        window = null;
        downstream.push(result);
      }
    }
  }
  return Gatherer.<TR, State, List<TR>>ofSequential(State::new, State::integrate, State::finish);
}

jshell> Stream.of("header", "value1", "value2", "header", "header", "value 3", "value 4", null).gather(windowBy(Predicate.not("header"::equals))).toList()
$1 ==> [[header, value1, value2], [header], [header, value 3, value 4, null]]


Hello,
I've two questions,
1/ Is there a reason why the integrator is not declared greedy (I'm still not sure to what exactly Greedy means in the context of gatherers) ?
2/ Is there a reason to write the code in a OOP way like you have done instead of only having fields in State and specify the behaviors using lambdas (because with lambdas will you get inference)

<T> Gatherer<T, ?, List<T>> windowBy(Predicate<? super T> includeInCurrentWindow) {
  class State {
    ArrayList<T> window;
  }
  return Gatherer.ofSequential(
      State::new,
      (state, element, downstream) -> {
       ...
      },
      (state, downstream) -> {
        ...
      });
}


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Wednesday, 10 January 2024 07:05
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Gatherers -- conditionalWindowFixed?

Hello Core Libs Dev Team,

I have been reading through JEP 461 (https://openjdk.org/jeps/461) about Gatherers, and I'm really excited for what this will enable for us.

By far, the most important functionality that this API facilitates is the ability to create windows. Anytime I needed a window, I was basically forced to use a for loop. Now, the 2 most common window cases are being handed to us for free. It is very much appreciated.

Could we add one more method for a conditionalWindowFixed? We would need to pass in some Predicate<T>. If the predicate returns true, create a list (if it does not already exist) then add the element to it. If the predicate returns false while the list is empty, then just move along to the next. Else if the predicate returns false while the list is non empty, pass the list down into the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

The reason I think this is worth adding is because it facilitates a really common use case. We may not want all windows to be the same size.

Is this something worth adding to the Gatherers API?

Thank you for your time and help!
David Alayachew

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

From alanb at openjdk.org  Wed Jan 10 20:33:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 20:33:23 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0" [v2]
In-Reply-To: <frm7iqwuvS3BN9ljqKt3OnUOWZDWN6Y9NiLN83yNXzU=.54eba6e5-7169-4975-835c-a03d786423a7@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
 <frm7iqwuvS3BN9ljqKt3OnUOWZDWN6Y9NiLN83yNXzU=.54eba6e5-7169-4975-835c-a03d786423a7@github.com>
Message-ID: <0LF0cbpRK5bgTzH7z5hbGy5XVc1hHMMWHblYIwMZVLw=.04fd868e-d76b-46dd-bb44-707b1345c669@github.com>

On Wed, 10 Jan 2024 18:03:32 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> While this might not fix 8314515, it should at least make it more exact.
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Cleaning up Fairness.java:s underlying queue implementation access
>  - Improving SynchronousQueue Fairness test to only proceed once observing that the previous thread is enqueued as a producer

Updated version looks much better.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17082#pullrequestreview-1814117488

From erikj at openjdk.org  Wed Jan 10 20:40:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Jan 2024 20:40:21 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
Message-ID: <qbJ6uvkQwriSG3dKDD78M40DSzDG5C6lUalNzk90c2E=.9d88e899-d49a-497d-9b8e-900e2713d489@github.com>

On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> JMH microbenchmarks may have dependencies on artifacts in the test image outside of the benchmarks.jar. This includes native libraries (built into `$TEST_IMAGE/micro/native`) and may soon include other test libraries like wb.jar (built into `$TEST_IMAGE/lib-test/`)
> 
> By moving execution to the test image root (currently we run out of the `make` directory) we can make do with relative paths, which means benchmark can supply a build-time constant flag themselves rather than have the test runner provide it for you. And needing to be explicit about external dependencies is good, I think.
> 
> Taken together this makes the benchmarks.jar more self-contained and simpler to run: all you need is to run `java -jar micro/benchmarks.jar` from the test image root.
> 
> This patch also drive-by fixes some lang.foreign tests that were printing warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag.

I think this is ok. For jtreg tests, we provide the path to the test image in a system property. I was going to suggest doing the same here, but referencing system properties in annotations isn't trivial. It would require implementing some kind of string interpolation for the `@Fork` annotation. Maybe that would still be more powerful and flexible if there are ever any other file paths that tests would need to reference into.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17349#pullrequestreview-1814130332

From mchung at openjdk.org  Wed Jan 10 20:47:48 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 10 Jan 2024 20:47:48 GMT
Subject: [jdk22] RFR: 8323547:
 tools/jlink/plugins/SystemModuleDescriptors/ModuleMainClassTest.java fails to
 compile
Message-ID: <ac6v2rg6wmcXfUXymePXcLQq3tg5xbAfsJSPvterZOg=.62dedff3-50da-4be3-b487-f9adafbeece8@github.com>

`jdk.test.lib.process.ProcessTools::executeTools` was modified to throw Exception by JDK-8322920 that has only been in the main line.   It's a mistake to backport JDK-8322809 without catching this.   Trivial fix - update the signature to throw Throwable instead.

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

Commit messages:
 - 8323547: tools/jlink/plugins/SystemModuleDescriptors/ModuleMainClassTest.java fails to compile

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

PR: https://git.openjdk.org/jdk22/pull/58

From bchristi at openjdk.org  Wed Jan 10 21:01:39 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 10 Jan 2024 21:01:39 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v5]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <l1C_LDyVmMAOAaydQemIcpa0KWYHfbsfg6HNL0sUBhc=.bc4ee308-ed4b-4e70-bc22-7c962d12b0ed@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:

  Remove hyphen in 'strongly reachable' in Cleaner

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/c09db360..9b4b1150

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

  Stats: 1 line in 1 file changed: 0 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 naoto at openjdk.org  Wed Jan 10 21:01:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 21:01:47 GMT
Subject: [jdk22] RFR: 8320788: The system properties page is missing some
 properties
Message-ID: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>

Backporting the document only fix to jdk22

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

Commit messages:
 - Backport 3bd9042054116365323912ed5867b70936fe85c4

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

PR: https://git.openjdk.org/jdk22/pull/59

From jlu at openjdk.org  Wed Jan 10 21:05:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:05:53 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v3]
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - Added comments for each test method

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

 - clarify locale issues (OS)
 - rename testRun -> test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17257/files
  - new: https://git.openjdk.org/jdk/pull/17257/files/a75237dc..c754893f

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

  Stats: 34 lines in 8 files changed: 5 ins; 2 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/17257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17257/head:pull/17257

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

From rriggs at openjdk.org  Wed Jan 10 21:07:23 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Jan 2024 21:07:23 GMT
Subject: [jdk22] RFR: 8320788: The system properties page is missing some
 properties
In-Reply-To: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>
References: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>
Message-ID: <bYGFviy3kUHJgY4YN0pbxPMW_sns9Qks6sbSZrRiKlY=.633a7437-627b-4bac-89ad-607d2ee5e834@github.com>

On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document only fix to jdk22

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/59#pullrequestreview-1814171861

From jlu at openjdk.org  Wed Jan 10 21:10:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:10:43 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses
Message-ID: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>

Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)

The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".

`MessageFormat` is the only Format subclass that can be constructed with a null locale, (hence the ternary in the implementation to prevent a potential NPE).
`ListFormat` already implemented toString(), and thus only the specification was updated to match the other Format subclasses.

An example of all the classes has output such as 


CompactNumberFormat [locale: "English (United States)", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]", decimal pattern: "foo#0.00#baz"]

DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]

SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]

ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]

MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]

ChoiceFormat [pattern: "0#foo"]

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

Commit messages:
 - init

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

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

From plevart at openjdk.org  Wed Jan 10 21:12:32 2024
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 10 Jan 2024 21:12:32 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment
Message-ID: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>

I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.

Am I right?

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

Commit messages:
 - fix mismatch avoidance of memory comparison

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

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

From naoto at openjdk.org  Wed Jan 10 21:20:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 21:20:26 GMT
Subject: [jdk22] RFR: 8323547:
 tools/jlink/plugins/SystemModuleDescriptors/ModuleMainClassTest.java fails to
 compile
In-Reply-To: <ac6v2rg6wmcXfUXymePXcLQq3tg5xbAfsJSPvterZOg=.62dedff3-50da-4be3-b487-f9adafbeece8@github.com>
References: <ac6v2rg6wmcXfUXymePXcLQq3tg5xbAfsJSPvterZOg=.62dedff3-50da-4be3-b487-f9adafbeece8@github.com>
Message-ID: <CPSU7idh1VYFjv4uFowPZlgQW58YnwSHW1oJ0KnfsgQ=.fe7e90a2-a5f1-4fa1-8c58-98e4ab52249c@github.com>

On Wed, 10 Jan 2024 20:43:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `jdk.test.lib.process.ProcessTools::executeTools` was modified to throw Exception by JDK-8322920 that has only been in the main line.   It's a mistake to backport JDK-8322809 without catching this.   Trivial fix - update the signature to throw Throwable instead.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/58#pullrequestreview-1814196312

From naoto at openjdk.org  Wed Jan 10 21:26:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 21:26:22 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v3]
In-Reply-To: <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>
Message-ID: <tSXAunh4gUfA3HiCYyesUb8XVFN7QgqfZh3JIF-g510=.f9267d23-83c2-4c92-97b3-469e08e2359f@github.com>

On Wed, 10 Jan 2024 21:05:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
>> 
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
>> 
>> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
>> 
>> Other updates
>> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
>> - Added comments for each test method
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - clarify locale issues (OS)
>  - rename testRun -> test

Still looks good. Please modify the copyright year for `HostLocaleProviderAdapter_md.c` file before integrating

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17257#pullrequestreview-1814204644

From lancea at openjdk.org  Wed Jan 10 21:29:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 10 Jan 2024 21:29:25 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits [v4]
In-Reply-To: <v76JlFNBZXCRcfJVhrngkQ7Oyz07dSFGCLrES08coT4=.f4053000-02ef-4432-84f7-652c30f34035@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
 <v76JlFNBZXCRcfJVhrngkQ7Oyz07dSFGCLrES08coT4=.f4053000-02ef-4432-84f7-652c30f34035@github.com>
Message-ID: <QndFZkeeVmdXl-xYJm-G5HqqGtkgd_j0iN6VgR_JCkM=.9c3c2889-5f12-4d8e-904d-bbb6f264c61a@github.com>

On Wed, 10 Jan 2024 18:29:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
>> 
>> 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)
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert TestPosix.java from testng to Junit 5

Thank you for the updates.  Looks good to go

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17170#pullrequestreview-1814209477

From lancea at openjdk.org  Wed Jan 10 21:30:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 10 Jan 2024 21:30:25 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v7]
In-Reply-To: <PuEqYTbKQV88c-f6tcR3zG5RqvHJ6elwfHADf-CnnvQ=.5607e70a-8aaf-4125-97dd-2f3543760b64@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>
 <PuEqYTbKQV88c-f6tcR3zG5RqvHJ6elwfHADf-CnnvQ=.5607e70a-8aaf-4125-97dd-2f3543760b64@github.com>
Message-ID: <x9q90Ba2TG_Cb5MZc_NBvwQXVsgonyC6PzGpT6Wjgjg=.b0a682e5-7b31-4fb3-a545-38e942d5b3ff@github.com>

On Fri, 15 Dec 2023 11:15:30 GMT, Lance Andersen <lancea 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.
>
>> 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...

> Thanks for your review, @LanceAndersen!
> 
> You might want to take a quick look at the lastest updates addressing your review before I integrate.

Looks good.  I am running mach5 tiers1-3 internally once it completes, I will approve again

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

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1885761673

From mchung at openjdk.org  Wed Jan 10 21:32:23 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 10 Jan 2024 21:32:23 GMT
Subject: [jdk22] Integrated: 8323547:
 tools/jlink/plugins/SystemModuleDescriptors/ModuleMainClassTest.java fails to
 compile
In-Reply-To: <ac6v2rg6wmcXfUXymePXcLQq3tg5xbAfsJSPvterZOg=.62dedff3-50da-4be3-b487-f9adafbeece8@github.com>
References: <ac6v2rg6wmcXfUXymePXcLQq3tg5xbAfsJSPvterZOg=.62dedff3-50da-4be3-b487-f9adafbeece8@github.com>
Message-ID: <fd9J2DpRrnPliChxmBAKAtqnTlG_b-iShnZlfxf8f1Q=.93183c35-9b2b-4320-8ab6-7f15d0dba58d@github.com>

On Wed, 10 Jan 2024 20:43:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `jdk.test.lib.process.ProcessTools::executeTools` was modified to throw Exception by JDK-8322920 that has only been in the main line.   It's a mistake to backport JDK-8322809 without catching this.   Trivial fix - update the signature to throw Throwable instead.

This pull request has now been integrated.

Changeset: 34222839
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/34222839e8a9094a12cf4a2a9acc9e7b228e6c40
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8323547: tools/jlink/plugins/SystemModuleDescriptors/ModuleMainClassTest.java fails to compile

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk22/pull/58

From iris at openjdk.org  Wed Jan 10 21:36:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 10 Jan 2024 21:36:23 GMT
Subject: [jdk22] RFR: 8320788: The system properties page is missing some
 properties
In-Reply-To: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>
References: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>
Message-ID: <1bkN676XqUCLhgMynC2DjSJ4rTZQ7IMpkO79spmotQA=.bb8a4e95-75b1-4f0a-ad01-8d991df0b251@github.com>

On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document only fix to jdk22

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/59#pullrequestreview-1814223539

From jlu at openjdk.org  Wed Jan 10 21:36:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:36:49 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v4]
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <xDmLm8bYH06H4aCvU8y0MnKWT1bVmStVznEuQaI1kWo=.767fde36-a114-453d-82cf-bd3109ca911b@github.com>

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - Added comments for each test method

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

  copyright year for HLPA_md.c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17257/files
  - new: https://git.openjdk.org/jdk/pull/17257/files/c754893f..a619b255

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

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

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

From jlu at openjdk.org  Wed Jan 10 21:36:50 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:36:50 GMT
Subject: RFR: JDK-8322235: Split up and improve LocaleProvidersRun [v3]
In-Reply-To: <tSXAunh4gUfA3HiCYyesUb8XVFN7QgqfZh3JIF-g510=.f9267d23-83c2-4c92-97b3-469e08e2359f@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>
 <tSXAunh4gUfA3HiCYyesUb8XVFN7QgqfZh3JIF-g510=.f9267d23-83c2-4c92-97b3-469e08e2359f@github.com>
Message-ID: <E0j-RGhypkTuylIjnJgwnuhY-rTX2VffS-a9FjTdAlM=.91bd1871-e995-41e4-85d2-3a105be94661@github.com>

On Wed, 10 Jan 2024 21:23:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Still looks good. Please modify the copyright year for `HostLocaleProviderAdapter_md.c` file before integrating

Totally missed that, thanks for catching. Will integrate after re-testing VM tiers.

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

PR Comment: https://git.openjdk.org/jdk/pull/17257#issuecomment-1885768744

From eirbjo at openjdk.org  Wed Jan 10 21:45:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 10 Jan 2024 21:45:33 GMT
Subject: Integrated: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits
In-Reply-To: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
References: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>
Message-ID: <hegZ0aURdEQglSTEfad6ElLpWU8j9BUigiZZ5ge7gqU=.6d6c4040-0b18-4af1-a022-b9f10b0863be@github.com>

On Wed, 20 Dec 2023 18:51:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> 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 instead of just the trailing 12 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`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value.
> 
> 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)

This pull request has now been integrated.

Changeset: e70cb4e6
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e70cb4e6c7fe131d585cfa3ff3b4dbeb4f9bbccd
Stats:     145 lines in 2 files changed: 109 ins; 9 del; 27 mod

8322565: (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits

Reviewed-by: clanger, lancea

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

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

From bchristi at openjdk.org  Wed Jan 10 21:52:29 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 10 Jan 2024 21:52:29 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v5]
In-Reply-To: <yTr1HPYE7IbNrDSy9BHXBg0JjF_ZNcagyYRf394fCrk=.d1e23d52-cbba-41a6-902d-0cc49024ab46@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <yTr1HPYE7IbNrDSy9BHXBg0JjF_ZNcagyYRf394fCrk=.d1e23d52-cbba-41a6-902d-0cc49024ab46@github.com>
Message-ID: <m5nRY03xUhnnLEjIp4oYX4C9GH_Wxszf_vadPxXCTm8=.4f9bb458-0ddf-412e-9217-583dc90c1b99@github.com>

On Sat, 18 Nov 2023 01:56:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove hyphen in 'strongly reachable' in Cleaner
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 399:
> 
>> 397:      * (or already completed) clearing and/or enqueueing this reference.
>> 398:      *
>> 399:      * Avoid this race by ensuring the referent remains strongly-reachable until
> 
> `s/strongly-reachable/strongly reachable/`  no dash as in other occurrences.

Changed in Cleaner, too

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1448025318

From bchristi at openjdk.org  Wed Jan 10 21:52:32 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 10 Jan 2024 21:52:32 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v4]
In-Reply-To: <bEgsmocaPXKYIS7whfKr7Gp5DratkzYprNB5PUv0fKM=.8a2fbf82-0a8b-4890-8b1c-a606ff2fd991@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <JvpXTdUylo-lBIa57VvYzHGWB7TKUFfg-J5xsKb6tVc=.7d9aef07-3a4d-44b0-a79e-27201f5d8b1e@github.com>
 <bEgsmocaPXKYIS7whfKr7Gp5DratkzYprNB5PUv0fKM=.8a2fbf82-0a8b-4890-8b1c-a606ff2fd991@github.com>
Message-ID: <UkOuQ0IHQvpSATCq029geYCdGutH2pI4yCAeA_f2qQY=.ba64373d-fedc-48b7-a7ee-8bf044c07f05@github.com>

On Wed, 10 Jan 2024 16:09:14 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> 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
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 499:
> 
>> 497:      * the reference is removed from the queue by {@link ReferenceQueue#poll}
>> 498:      * or {@link ReferenceQueue#remove}. An <b><i>unsuccessful</i></b>
>> 499:      * {@code enqueue} call has no memory consistency effects.
> 
> Would it help to say that unsuccessful enqueue calls have no *reliable* or *specified* memory consistency effects?

Yes, I like that phrasing better, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1448025551

From bchristi at openjdk.org  Wed Jan 10 22:12:40 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 10 Jan 2024 22:12:40 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v6]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <VU_oK39fLPRq6d32t1tvSLIHLTOdIItkGsTbXuVcKAM=.2b939eb4-0610-4efb-af28-3c9025100e58@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:

  Tweak Reference.enqueue memory consistency effects wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/9b4b1150..3647f64a

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 mcimadamore at openjdk.org  Wed Jan 10 22:15:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Jan 2024 22:15:21 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment
In-Reply-To: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
Message-ID: <2q1zKN2-XO1OqAcVi9Dk5_adA1zyWhPmfTxwR2r-GP0=.8588ed20-6c48-42c3-88ab-7c6645878d78@github.com>

On Wed, 10 Jan 2024 20:54:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
> 
> Am I right?

Note there's another bug for this: https://bugs.openjdk.org/browse/JDK-8323524

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 684:

> 682:         srcImpl.checkAccess(srcFromOffset, srcBytes, true);
> 683:         dstImpl.checkAccess(dstFromOffset, dstBytes, true);
> 684:         if (dstImpl.equals(srcImpl) && srcFromOffset == dstFromOffset && srcBytes == dstBytes) {

I'm also ok to completely drop this check (or move it into the instance version of the mismatch method). This also needs a test.

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

PR Comment: https://git.openjdk.org/jdk/pull/17354#issuecomment-1885824510
PR Review Comment: https://git.openjdk.org/jdk/pull/17354#discussion_r1448045022

From lancea at openjdk.org  Wed Jan 10 22:46:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 10 Jan 2024 22:46:25 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v10]
In-Reply-To: <KfbG7_NOlWac77gZ_MqSsamuKCl0zuPnmPWetPiVpjc=.74e5f69b-e218-4cb2-878a-8c733594209f@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <KfbG7_NOlWac77gZ_MqSsamuKCl0zuPnmPWetPiVpjc=.74e5f69b-e218-4cb2-878a-8c733594209f@github.com>
Message-ID: <wO6G5ICDNGrfTZKwvazd_sS9uih3YbrAZuMyCMYBnvk=.f2b222f3-9271-4ba4-89f4-d9aa25831b36@github.com>

On Tue, 9 Jan 2024 07:29:49 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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. A new test case `noentries()` was added, resolving [JDK-8322830](https://bugs.openjdk.org/browse/JDK-8322830)
>> 
>> `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 ...
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments for ZIP64 End Of Central header tests
>  - Copyright update for 2024

Internal mach5 tiers 1-3 completed

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17038#pullrequestreview-1814329966

From naoto at openjdk.org  Thu Jan 11 00:06:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Jan 2024 00:06:30 GMT
Subject: [jdk22] Integrated: 8320788: The system properties page is missing
 some properties
In-Reply-To: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>
References: <Gp7WsBfgYJ7lzf-a33SajCiMGVE8uxcdGDlsW5TMh7s=.4564a14d-6d4c-4733-807d-9b3d4c895659@github.com>
Message-ID: <MuWYM53BS2rJv7qf0BdsocNLcOcOGb31gJa0rJW1rAc=.52b92a15-1c5c-4f00-a0b4-749ccf5060e6@github.com>

On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document only fix to jdk22

This pull request has now been integrated.

Changeset: 6951987b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/6951987b65e50143ee3f1f79f7731159a0310223
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8320788: The system properties page is missing some properties

Reviewed-by: rriggs, iris
Backport-of: 3bd9042054116365323912ed5867b70936fe85c4

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

PR: https://git.openjdk.org/jdk22/pull/59

From tprinzing at openjdk.org  Thu Jan 11 00:43:53 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 11 Jan 2024 00:43:53 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v4]
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: <y3n2bSkIvLh2w_B6YmtZFdpSst81IWlk2MYfuCEiiP4=.7bf23ddf-e7e1-4dbf-8303-873550d370ef@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:

  comment fixup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/13262293..18064cd1

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

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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  Thu Jan 11 03:09:35 2024
From: duke at openjdk.org (duke)
Date: Thu, 11 Jan 2024 03:09:35 GMT
Subject: Withdrawn: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <Whzj27D8ZNlGQ96zERlmMzBBO5KJl_OCTHKeMiMDVYo=.d1cfba1e-5c83-401a-b057-d8ce8ed403f3@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.org  Thu Jan 11 05:49:27 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 Jan 2024 05:49:27 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <s75cIa_CJBjOl0qhza78g4llQSruDnC9UURHoWP7HG4=.25aa8b0d-3f35-43c9-be1a-bd97853e8173@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <Yk28MAUo0THuTa083uu-GCAVQiUiQ5RM7N_fXwsERQ4=.d6e51491-ca9a-40fb-b7aa-a8d98d762ec8@github.com>
 <s75cIa_CJBjOl0qhza78g4llQSruDnC9UURHoWP7HG4=.25aa8b0d-3f35-43c9-be1a-bd97853e8173@github.com>
Message-ID: <vlaG5Pj2mQuMM4XHiDSUU0rFfsGM12NEmjYzgK_gf44=.207b8230-10cf-491d-a6f9-5feb52abf191@github.com>

On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> > Sounds like a CSR is needed for the behavioral change proposed here.
> 
> Thanks for flagging this @jddarcy
> 
> I'm personally not 100% convinced a CSR is warranted in this case, but I'm of course happy to extend the following into a CSR if you or other reviewer think that's the best way forward:
> 
> Let's review the intended and unintended behavioral changes in this PR:
> 
> The _intended_ behavioral change is to extend the set of ZIP entries parsable by `ZipInputStream` to include "small Zip64 entries". Such entries meet the following criteria:
> 
>     1. They are clearly marked as using the Zip64 format, meaning that the LOC's 'compressed size' and 'uncompressed size' fields are set to the "Zip64 magic value" 0xFFFFFFFF and that the LOC's extra field includes a valid _Zip64 Extended Information Field_.
> 
>     2. They use _streaming mode_, meaning that the 'general purpose bit flag' 3 is set, that the Zip64 'Original Size' and 'Compressed Size' are both set to zero and that file data is followed by a 'Data Descriptor' containing the actual size values.
> 
>     3. The Data Descriptor represents the 'compressed size' and 'uncompressed' size fields using 8 byte fields, instead of the regular 4 byte fields.
> 
> 
> These entires are currently not parsable by `ZipInputStream`. Trying to parse them fails with an exception similar to the following:
> 
> ```
> java.util.zip.ZipException: invalid entry size (expected 0 but got 6 bytes)
> 	at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:616)
> ```
> 
> The _unintended_ behavioral change in this PR is that ZIP entries marked as Zip64, but still having a Data Descriptor using 4 bytes to represent the size fields will now become unparsable. Such entries meet critera 1 and 2 above, but not 3.
> 
> While I have not performed a corpus search, I believe such entries are rare, if they exist at all:
> 
>     * They would be in clear violation of the `APPNOTE.txt` spec, which in 4.3.9.2 says  _ZIP64 format MAY be used regardless of the size of a file.  When extracting, if the zip64 extended information extra field is present for the file the compressed and uncompressed sizes will be 8 byte values_
> 
>     * The `zipdetails` tool fails to parse such a file, instead reading the two 4-byte numbers into one 8-byte 'compressed size'
> 
>     * The file cannot be parsed by external APIs similar to `ZipInputStream`, such as the Python `stream-unzip` module.
> 
> 
> To avoid unintended behavioral changes in the implementation, care has been taken to make the Zip64 extra field validation code robust to invalid input, including out of bounds array access.
> 
> To summarize, this PR aims to allow a set of useful, valid ZIP files to be parsed, at the cost of potentially making a small set of invalid ZIP files unparsable.

@eirbjo, either of the intended or unintended effects of the PR on their own would merit a CSR and this is a case where the inclusive-OR applies so a CSR is definitely needed; thanks.

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

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

From eirbjo at openjdk.org  Thu Jan 11 06:35:32 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 11 Jan 2024 06:35:32 GMT
Subject: Integrated: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <fOD80guwwAW1rShpPIhWuhAXPB8DagbIGM87cVI7UHc=.8f94c48d-c8b5-4bc0-902c-6c6b5061bd94@github.com>

On Fri, 8 Dec 2023 20:28:20 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> 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. A new test case `noentries()` was added, resolving [JDK-8322830](https://bugs.openjdk.org/browse/JDK-8322830)
> 
> `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.

This pull request has now been integrated.

Changeset: 26de9e24
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26de9e247a6ed1c0b8b247d77514ed16905d7c48
Stats:     1120 lines in 14 files changed: 565 ins; 283 del; 272 mod

8321616: Retire binary test vectors in test/jdk/java/util/zip/ZipFile
8322830: Add test case for ZipFile opening a ZIP with no entries

Reviewed-by: lancea

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

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

From alanb at openjdk.org  Thu Jan 11 07:45:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 07:45:31 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
Message-ID: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>

This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.

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

Commit messages:
 - Initial commit

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

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

From pminborg at openjdk.org  Thu Jan 11 07:59:37 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 11 Jan 2024 07:59:37 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v2]
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <-gjTiaVmyJT28RbwaFpTi1rj-7RMaUwAOc382xheR8k=.96c62e45-320e-4fd4-8d4c-73f3553eba9b@github.com>

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

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

  Move and change text on zeroing out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17308/files
  - new: https://git.openjdk.org/jdk/pull/17308/files/4c777398..04074d71

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

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

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

From alanb at openjdk.org  Thu Jan 11 08:03:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 08:03:31 GMT
Subject: RFR: 8320788: The system properties page is missing some
 properties [v3]
In-Reply-To: <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
Message-ID: <Sbtda0eu1Y-X_5BWycnC4O-puqpIcE2LJijAeTDkUbU=.51881cb8-6706-4183-9f46-670f3700df60@github.com>

On Tue, 9 Jan 2024 23:40:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also 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 18 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8320788-system.getProperties
>  - Reflects review comments
>  - initial commit
>  - 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>
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/376051a9...7444bb51

We need to think about whether the change proposed here will set precedence or not. There are many places in the API docs where system properties are specified but they aren't linked from System::getProperties.

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

PR Comment: https://git.openjdk.org/jdk/pull/17317#issuecomment-1886570976

From vklang at openjdk.org  Thu Jan 11 08:19:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 11 Jan 2024 08:19:31 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0" [v2]
In-Reply-To: <0LF0cbpRK5bgTzH7z5hbGy5XVc1hHMMWHblYIwMZVLw=.04fd868e-d76b-46dd-bb44-707b1345c669@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
 <frm7iqwuvS3BN9ljqKt3OnUOWZDWN6Y9NiLN83yNXzU=.54eba6e5-7169-4975-835c-a03d786423a7@github.com>
 <0LF0cbpRK5bgTzH7z5hbGy5XVc1hHMMWHblYIwMZVLw=.04fd868e-d76b-46dd-bb44-707b1345c669@github.com>
Message-ID: <zKaVvJJNpjgatU58D6t_lWjeo9DHkLxZTf16O-HvFIE=.ca9fddc4-3fa8-4667-9ed3-cfe4067a2d70@github.com>

On Wed, 10 Jan 2024 20:30:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updated version looks much better.

Thanks @AlanBateman!

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

PR Comment: https://git.openjdk.org/jdk/pull/17082#issuecomment-1886591099

From vklang at openjdk.org  Thu Jan 11 08:19:33 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 11 Jan 2024 08:19:33 GMT
Subject: Integrated: 8314515:
 java/util/concurrent/SynchronousQueue/Fairness.java failed with
 "Error: fair=false i=8 j=0"
In-Reply-To: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
References: <cWlfo0tvSH2HAi9CAN5EQ4_X7OIUd2BiH29tTeUyr5Q=.26e46bea-2cbf-4b8b-8040-838e40be3a8d@github.com>
Message-ID: <5PsG2-8vLeWDAqTRdafnrGQgyy4851Jarp5OzHY-K4k=.11983607-b6aa-4d3c-a37c-dc3b6b6d55cb@github.com>

On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While this might not fix 8314515, it should at least make it more exact.

This pull request has now been integrated.

Changeset: 35e96627
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35e9662767cc0a1dea9b5afa2a6d61a85297253c
Stats:     35 lines in 1 file changed: 28 ins; 0 del; 7 mod

8314515: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=false i=8 j=0"

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Thu Jan 11 09:41:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 09:41:24 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier [v2]
In-Reply-To: <nWRuECg40mF-hrg0W0bXRoifp2GIsMZMu5LDnygTrK8=.208cfb34-6d54-4fe1-a38e-3b07e369bcff@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
 <nWRuECg40mF-hrg0W0bXRoifp2GIsMZMu5LDnygTrK8=.208cfb34-6d54-4fe1-a38e-3b07e369bcff@github.com>
Message-ID: <PEM-6f-vPXIgDPaXiYOWX9lVrSgIpuavUW00j_Q7TxI=.abea3ec0-3e67-44ea-b9ae-804121198475@github.com>

On Wed, 10 Jan 2024 10:17:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback.
>
> src/java.base/share/classes/java/lang/reflect/Modifier.java line 238:
> 
>> 236:      * modifiers of a class or member, source-level modifiers that do
>> 237:      * not <em>not</em> have a constant in the this class should be
>> 238:      * included and ordered consistent with the full recommended
> 
> Suggestion:
> 
>      * included and ordered consistently with the full recommended

Yes, "ordered consistently with" or "with order consistent with", I think both will work here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17338#discussion_r1448564687

From simonis at openjdk.org  Thu Jan 11 09:42:25 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 11 Jan 2024 09:42:25 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <AmlJOs7hkqD5rZCH-zPQzEaZOWNmg7VQS2TIJkDEbig=.be56cd27-bebe-49c2-8092-e6b98989daf0@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
 <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>
 <AmlJOs7hkqD5rZCH-zPQzEaZOWNmg7VQS2TIJkDEbig=.be56cd27-bebe-49c2-8092-e6b98989daf0@github.com>
Message-ID: <tGw8-oOblGEriLtfGjyx3NWJoEUGX9U5BCNn3Qyq78U=.01a8ff07-6ee0-4e37-aeaf-cf34685401dc@github.com>

On Mon, 8 Jan 2024 20:27:59 GMT, Joshua Cao <duke at openjdk.org> wrote:

> We don't need to compute max() here. [tryPresize()](https://github.com/openjdk/jdk/blob/8a4dc79e1a40e7115e2971af81623b6b0368f41c/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2397) does that already.

The code you reference is only executed if `table == null` but in this case we know it is not `null` because we only call `tryPresize()` if `table != null`.

In general, it's hard fro me to understand what `tryPresize(int size)` is doing and if its `size` argument is supposed to contain the additional number of elements which will be inserted into the hash map or if it is a hint for the new total size of the hash map. Can you explain?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1448566797

From jkratochvil at openjdk.org  Thu Jan 11 09:46:22 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 11 Jan 2024 09:46:22 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
Message-ID: <VKsuzL5_-W3S9TekcgcjEdOJYymCaOO4wdC70TNYtsA=.f4a1c0ad-544f-43b3-91f6-0d44edb3098b@github.com>

On Thu, 28 Dec 2023 15:19:23 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> 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

ping, are there some concerns during review of this patch? If you don't like too much some part just point at it, I will try to improve it. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1886731985

From prappo at openjdk.org  Thu Jan 11 10:34:45 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 10:34:45 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v12]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <5_1gzLTndIAda1lyk_zRhWZ2Kk28UL7jOLE3x9mOhf0=.394870e7-ffec-4b81-9944-4b851b98c3d6@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 incrementally with one additional commit since the last revision:

  Revert copyright year change
  
  Those files were first published in 2023 and haven't been changed since.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/08e6adca..31e9eefd

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

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 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 rgiulietti at openjdk.org  Thu Jan 11 10:39:26 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 11 Jan 2024 10:39:26 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v12]
In-Reply-To: <5_1gzLTndIAda1lyk_zRhWZ2Kk28UL7jOLE3x9mOhf0=.394870e7-ffec-4b81-9944-4b851b98c3d6@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <5_1gzLTndIAda1lyk_zRhWZ2Kk28UL7jOLE3x9mOhf0=.394870e7-ffec-4b81-9944-4b851b98c3d6@github.com>
Message-ID: <2qsP_pwHh9y53rn6bylDc99seoAoYXLtIgxi9P4_cig=.fd922da8-beb2-4bb0-9ee2-7d8134cdb4de@github.com>

On Thu, 11 Jan 2024 10:34:45 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 incrementally with one additional commit since the last revision:
> 
>   Revert copyright year change
>   
>   Those files were first published in 2023 and haven't been changed since.

LGTM

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14630#pullrequestreview-1815217411

From duke at openjdk.org  Thu Jan 11 11:00:33 2024
From: duke at openjdk.org (duke)
Date: Thu, 11 Jan 2024 11:00:33 GMT
Subject: Withdrawn: 8319200: Don't use test thread factory in
 ProcessTools.createLimitedTestJavaProcessBuilder()
In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com>
References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com>
Message-ID: <URiTihUQLvbQRgheHpm7vOvVUQzUsCk-zlEVY2lBiGs=.5f719956-5112-440c-928f-6ac212a91fa2@github.com>

On Wed, 1 Nov 2023 00:06:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options.
> 
> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder().
> 
> Testing tier1-5.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Thu Jan 11 11:26:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Jan 2024 11:26:22 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
Message-ID: <2NoIg0vVwzRQQUMAGHm8nMzghFse2GYUj4NcN0XptII=.21965723-5c27-4fcc-b065-901fb4a59b9e@github.com>

On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> JMH microbenchmarks may have dependencies on artifacts in the test image outside of the benchmarks.jar. This includes native libraries (built into `$TEST_IMAGE/micro/native`) and may soon include other test libraries like wb.jar (built into `$TEST_IMAGE/lib-test/`)
> 
> By moving execution to the test image root (currently we run out of the `make` directory) we can make do with relative paths, which means benchmark can supply a build-time constant flag themselves rather than have the test runner provide it for you. And needing to be explicit about external dependencies is good, I think.
> 
> Taken together this makes the benchmarks.jar more self-contained and simpler to run: all you need is to run `java -jar micro/benchmarks.jar` from the test image root.
> 
> This patch also drive-by fixes some lang.foreign tests that were printing warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag.

In principle, I think tests should be executed from their corresponding test-support directory. (I think there is some JBS issue for this that's been around for some while.) The rationale is that this is a good directory for any arbitrary output generated from the test, for files that are just dumped in the current directory. (This happens from time to time with tests.)

But if executing from the test image improves the code quality of the tests, I am not going to argue heavily against it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17349#issuecomment-1886933844

From abimpoudis at openjdk.org  Thu Jan 11 11:51:30 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 11 Jan 2024 11:51:30 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v38]
In-Reply-To: <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com>
Message-ID: <vhA8S4Czyp6I1yFT8qb3Hgi_KStSLTygVN7mpxGWpJo=.e5d27f96-7874-4315-b77a-85090edbc55c@github.com>

On Thu, 14 Dec 2023 11:04:09 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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

Keep open ???

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1886978935

From jpai at openjdk.org  Thu Jan 11 12:01:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Jan 2024 12:01:28 GMT
Subject: [jdk22] RFR: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
References: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
Message-ID: <x5Hf4lpIYjBa8KFCSqVx9DzkrcnUEKzoutck0BIrGfA=.84642aaa-ee2e-4cdd-9da0-f85f629f1331@github.com>

On Wed, 10 Jan 2024 17:42:21 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> 
> It needs to be backported to JDK22.

Clean backport of a P3 bug fix.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/56#pullrequestreview-1815371942

From jvernee at openjdk.org  Thu Jan 11 12:12:33 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 11 Jan 2024 12:12:33 GMT
Subject: [jdk22] Integrated: 8322324: java/foreign/TestStubAllocFailure.java
 times out while waiting for forked process
In-Reply-To: <rHVeex3NSElclhVhKGYga0pfQUCycGqFkR4mizrY6Cc=.619c98f8-df51-4029-a610-8804514c595f@github.com>
References: <rHVeex3NSElclhVhKGYga0pfQUCycGqFkR4mizrY6Cc=.619c98f8-df51-4029-a610-8804514c595f@github.com>
Message-ID: <zlMQZea0DERwzs7Z0-r6GdUSuXPT6XZ1IDVUO9rkS7A=.b90e9f8f-11fa-4f47-a887-0ef9c2089db6@github.com>

On Wed, 10 Jan 2024 13:18:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d2d58dd6](https://github.com/openjdk/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 10 Jan 2024 and was reviewed by Maurizio Cimadamore.
> 
> This is a P2 test only change, and we are currently in Ramp Down Phase 1. The release process allows P1-P5 test-only changes during RDP1: https://openjdk.org/jeps/3#Quick-reference
> 
> Thanks!

This pull request has now been integrated.

Changeset: db342758
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/db3427582df5913e9299e8ecceecd9bddb3b7358
Stats:     16 lines in 1 file changed: 3 ins; 0 del; 13 mod

8322324: java/foreign/TestStubAllocFailure.java times out while waiting for forked process
8322637: java/foreign/critical/TestCriticalUpcall.java timed out

Reviewed-by: mcimadamore
Backport-of: d2d58dd6a8ec366a4bc3eb12a253b252de24557e

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

PR: https://git.openjdk.org/jdk22/pull/52

From wxiao at openjdk.org  Thu Jan 11 12:19:29 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 11 Jan 2024 12:19:29 GMT
Subject: [jdk22] Integrated: 8318971: Better Error Handling for Jar Tool When
 Processing Non-existent Files
In-Reply-To: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
References: <jTWQF-60xuEjejpEL_mKd3LoZL5u8u7XJGQJ2AGYfAM=.44f6ec3a-92d3-4dc2-b2da-d22413891f18@github.com>
Message-ID: <yQaueagMVIvdR7giUl0JyTtO9jPR2ASBz-l3Lnn-sK8=.2a72d9b6-bc5f-48c4-a046-28e8accb1893@github.com>

On Wed, 10 Jan 2024 17:42:21 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> Better Error Handling for Jar Tool When Processing Non-existent Files. <br>
> 
> It needs to be backported to JDK22.

This pull request has now been integrated.

Changeset: 3daa936f
Author:    Weibing Xiao <wxiao at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/3daa936f2da4da853e0cbe8dcb081e3a7509734f
Stats:     86 lines in 2 files changed: 84 ins; 0 del; 2 mod

8318971: Better Error Handling for Jar Tool When Processing Non-existent Files

Reviewed-by: jpai
Backport-of: 8ae309ebacd6947bbad2ef168ca13702e1cba099

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

PR: https://git.openjdk.org/jdk22/pull/56

From sspitsyn at openjdk.org  Thu Jan 11 13:09:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Jan 2024 13:09:39 GMT
Subject: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be
 static [v2]
In-Reply-To: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
References: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
Message-ID: <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>

> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
> The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
> The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
> One detail to underline is that he intrinsic implementation needs to use the argument #0 instead of #1.
> 
> Testing:
> - The mach5 tiers 1-6 show no regressions

Serguei Spitsyn has updated the pull request with a new target base 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
 - 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17298/files
  - new: https://git.openjdk.org/jdk/pull/17298/files/2b684607..66bcce95

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

  Stats: 17642 lines in 345 files changed: 12363 ins; 3111 del; 2168 mod
  Patch: https://git.openjdk.org/jdk/pull/17298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17298/head:pull/17298

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

From jpai at openjdk.org  Thu Jan 11 13:24:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Jan 2024 13:24:26 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
In-Reply-To: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
Message-ID: <URdsnXmQf9v2PJQlbe4t81NZRIECVbK0v7daOfnHh2M=.e44b8f94-9e49-4f34-917b-41b04a24f730@github.com>

On Wed, 10 Jan 2024 20:25:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.

test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java line 52:

> 50:         // need at least two carrier threads when main thread is a virtual thread
> 51:         if (Thread.currentThread().isVirtual()) {
> 52:             VThreadRunner.ensureParallelism(2);

Given that this changes the JVM level scheduler's parallelism, should we now use `/othervm` for these tests to prevent this change interfering with other tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17353#discussion_r1448858813

From plevart at openjdk.org  Thu Jan 11 13:30:44 2024
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 11 Jan 2024 13:30:44 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment [v2]
In-Reply-To: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
Message-ID: <bcyiiMVUnCHutl4TIoKMCyrKcpq62CAFNh1SilLqnTM=.f5f8d0d8-2195-4de3-9a16-1d90f4583b0c@github.com>

> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
> 
> Am I right?

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

  move special-case check for equal segments to the instance method (more probable)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17354/files
  - new: https://git.openjdk.org/jdk/pull/17354/files/7bcf0273..5112839b

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

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

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

From jpai at openjdk.org  Thu Jan 11 13:52:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Jan 2024 13:52:25 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
In-Reply-To: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
Message-ID: <F6OxdXHH3yuQf8ZFDckQiK7uYtdeWHmkEH8Sd0Mv6II=.46fb9e35-4cc8-4a67-bb2b-624bea71cfe4@github.com>

On Wed, 10 Jan 2024 20:25:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.

test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java line 65:

> 63:             for (int i = 0; i < iterations; i++) {
> 64:                 // wait for main thread to arrive
> 65:                 barrier.await();

Given the goal of this test, which is "Stress test Thread.getStackTrace on a virtual thread that is pinned", shouldn't this `barrier.await()` be a few lines below, inside the `synchronized (GetStackTraceALotWhenPinned.class)` block, just before it parks itself? That way, the main thread when it too reaches the barrier and when it next issues a getStackTrace() call, the chances of the other thread being pinned would be high(er)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17353#discussion_r1448894710

From alanb at openjdk.org  Thu Jan 11 14:14:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 14:14:23 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
In-Reply-To: <F6OxdXHH3yuQf8ZFDckQiK7uYtdeWHmkEH8Sd0Mv6II=.46fb9e35-4cc8-4a67-bb2b-624bea71cfe4@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
 <F6OxdXHH3yuQf8ZFDckQiK7uYtdeWHmkEH8Sd0Mv6II=.46fb9e35-4cc8-4a67-bb2b-624bea71cfe4@github.com>
Message-ID: <JHbzrPT6FCxYCmUor5m9vsrr_kNWcaCJ3__BsBq0CtY=.0c4eea0f-3bbd-4cd1-b0d1-8b4c77a5fb31@github.com>

On Thu, 11 Jan 2024 13:49:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.
>
> test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java line 65:
> 
>> 63:             for (int i = 0; i < iterations; i++) {
>> 64:                 // wait for main thread to arrive
>> 65:                 barrier.await();
> 
> Given the goal of this test, which is "Stress test Thread.getStackTrace on a virtual thread that is pinned", shouldn't this `barrier.await()` be a few lines below, inside the `synchronized (GetStackTraceALotWhenPinned.class)` block, just before it parks itself? That way, the main thread when it too reaches the barrier and when it next issues a getStackTrace() call, the chances of the other thread being pinned would be high(er)?

It's in the right place. This is a stress test to bash on Thread::getStackTrace where the target virtual thread is transitioning from being unmounted to parked-while-pinned. There are intermittent states and the stack walk will depend on whether the target is mounted or not. There are other tests that exercise Thread::getStackTrace on pinned threads, specifically ThreadAPI.testGetStackTrace6 and ThreadAPI.testGetStackTrace7, but different to the stress testing that is done here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17353#discussion_r1448924715

From jpai at openjdk.org  Thu Jan 11 14:19:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Jan 2024 14:19:24 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
In-Reply-To: <JHbzrPT6FCxYCmUor5m9vsrr_kNWcaCJ3__BsBq0CtY=.0c4eea0f-3bbd-4cd1-b0d1-8b4c77a5fb31@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
 <F6OxdXHH3yuQf8ZFDckQiK7uYtdeWHmkEH8Sd0Mv6II=.46fb9e35-4cc8-4a67-bb2b-624bea71cfe4@github.com>
 <JHbzrPT6FCxYCmUor5m9vsrr_kNWcaCJ3__BsBq0CtY=.0c4eea0f-3bbd-4cd1-b0d1-8b4c77a5fb31@github.com>
Message-ID: <gWKbEc8QJ1iTEATLnOBW5tlUiOGzLhKv3hjrZPZ_Vs8=.01cc5a76-af21-47cb-a576-419d92f65c2c@github.com>

On Thu, 11 Jan 2024 14:12:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are intermittent states and the stack walk will depend on whether the target is mounted or not. 

Thank you for that detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17353#discussion_r1448930993

From erikj at openjdk.org  Thu Jan 11 14:20:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Jan 2024 14:20:22 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <2NoIg0vVwzRQQUMAGHm8nMzghFse2GYUj4NcN0XptII=.21965723-5c27-4fcc-b065-901fb4a59b9e@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
 <2NoIg0vVwzRQQUMAGHm8nMzghFse2GYUj4NcN0XptII=.21965723-5c27-4fcc-b065-901fb4a59b9e@github.com>
Message-ID: <P1UtBu8Y-P-vN9LIca91jVUvr6RvNRr5BfFDl_tmekQ=.df1e19f9-84dc-403b-9098-970113530538@github.com>

On Thu, 11 Jan 2024 11:23:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In principle, I think tests should be executed from their corresponding test-support directory. (I think there is some JBS issue for this that's been around for some while.) The rationale is that this is a good directory for any arbitrary output generated from the test, for files that are just dumped in the current directory. (This happens from time to time with tests.)

Magnus does bring up a good point. The root of the test image is a very bad place to accidentally drop arbitrary files when run in our distributed test system, but we don't really run the micros there, at least not like this, do we?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17349#issuecomment-1887269464

From sgehwolf at openjdk.org  Thu Jan 11 14:34:23 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 11 Jan 2024 14:34:23 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
Message-ID: <LvdIGJytkMjLwZufcbUUfJW2Dr1laNMZVx_O-V_l3P8=.b216fc1b-95f7-4d73-94f4-8260b713a375@github.com>

On Thu, 28 Dec 2023 15:19:23 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> 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

I'm looking at it. Review should be ready this or early next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1887311496

From redestad at openjdk.org  Thu Jan 11 15:07:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 11 Jan 2024 15:07:24 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <P1UtBu8Y-P-vN9LIca91jVUvr6RvNRr5BfFDl_tmekQ=.df1e19f9-84dc-403b-9098-970113530538@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
 <2NoIg0vVwzRQQUMAGHm8nMzghFse2GYUj4NcN0XptII=.21965723-5c27-4fcc-b065-901fb4a59b9e@github.com>
 <P1UtBu8Y-P-vN9LIca91jVUvr6RvNRr5BfFDl_tmekQ=.df1e19f9-84dc-403b-9098-970113530538@github.com>
Message-ID: <yg4uRQ9BT5mIyrvo3RnOwc6Ic1Ue1dLc0gqbYvAWXAM=.4be0b600-2cc9-4120-9b83-e421bdbccc7c@github.com>

On Thu, 11 Jan 2024 14:17:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In principle, I think tests should be executed from their corresponding test-support directory. (I think there is some JBS issue for this that's been around for some while.) The rationale is that this is a good directory for any arbitrary output generated from the test, for files that are just dumped in the current directory. (This happens from time to time with tests.)
>> 
>> But if executing from the test image improves the code quality of the tests, I am not going to argue heavily against it.
>
>> In principle, I think tests should be executed from their corresponding test-support directory. (I think there is some JBS issue for this that's been around for some while.) The rationale is that this is a good directory for any arbitrary output generated from the test, for files that are just dumped in the current directory. (This happens from time to time with tests.)
> 
> Magnus does bring up a good point. The root of the test image is a very bad place to accidentally drop arbitrary files when run in our distributed test system, but we don't really run the micros there, at least not like this, do we?

If the test image dir could be relative to the test-support directory (via a symlink, or knowing that `../test/` always points to the test image) then running from out of there could work. As @erikj79 has figured out then the root issue for me here is that it's not feasible to pass the test image directory as a parameter (since the `@Fork` annotation needs compile-time constants), so if it's possible to configure test-support directories to be in arbitrary places then that would become very fragile.

None of our JMH tests pollutes the current directory as far as I'm aware, though. And if they did the current situation where the micros are run out of the make directory might arguably be worse.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17349#issuecomment-1887373227

From jvernee at openjdk.org  Thu Jan 11 15:26:25 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 11 Jan 2024 15:26:25 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment [v2]
In-Reply-To: <bcyiiMVUnCHutl4TIoKMCyrKcpq62CAFNh1SilLqnTM=.f5f8d0d8-2195-4de3-9a16-1d90f4583b0c@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
 <bcyiiMVUnCHutl4TIoKMCyrKcpq62CAFNh1SilLqnTM=.f5f8d0d8-2195-4de3-9a16-1d90f4583b0c@github.com>
Message-ID: <oC_djDiCV3Jp03loRyooCL9_KteVWu4xYjBFH6PoaDQ=.d971f11b-e8f3-48c5-8c6f-87bace078ef8@github.com>

On Thu, 11 Jan 2024 13:30:44 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
>> 
>> Am I right?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move special-case check for equal segments to the instance method (more probable)

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 299:

> 297:             checkValidState();
> 298:             return -1;
> 299:         }

I'm skeptical of trying to optimize this without a more thorough performance investigation. We shouldn't add this complexity on a whim.

I'm more in favor of just dropping the check from the static mismatch method and leaving it at that. (And adding a test as Maurizio mentioned).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17354#discussion_r1449022827

From plevart at openjdk.org  Thu Jan 11 16:21:38 2024
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 11 Jan 2024 16:21:38 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment [v3]
In-Reply-To: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
Message-ID: <GX3AHG5TyzYjqOMIDu54uAQlFN4DEL67L1GVcraOMhM=.6246b527-d3da-4783-8e53-5ff6cd921443@github.com>

> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
> 
> Am I right?

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  remove special-case check from instance method - test pending

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17354/files
  - new: https://git.openjdk.org/jdk/pull/17354/files/5112839b..22417ea3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17354&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17354&range=01-02

  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17354/head:pull/17354

PR: https://git.openjdk.org/jdk/pull/17354

From plevart at openjdk.org  Thu Jan 11 16:21:40 2024
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 11 Jan 2024 16:21:40 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment [v2]
In-Reply-To: <oC_djDiCV3Jp03loRyooCL9_KteVWu4xYjBFH6PoaDQ=.d971f11b-e8f3-48c5-8c6f-87bace078ef8@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
 <bcyiiMVUnCHutl4TIoKMCyrKcpq62CAFNh1SilLqnTM=.f5f8d0d8-2195-4de3-9a16-1d90f4583b0c@github.com>
 <oC_djDiCV3Jp03loRyooCL9_KteVWu4xYjBFH6PoaDQ=.d971f11b-e8f3-48c5-8c6f-87bace078ef8@github.com>
Message-ID: <w9ZqvHsuIXh6aI5PZNokAyxmMxjk7R3C-V-5fh4rYNk=.99ac2a71-152d-4235-959a-15b9ce9773be@github.com>

On Thu, 11 Jan 2024 15:23:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move special-case check for equal segments to the instance method (more probable)
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 299:
> 
>> 297:             checkValidState();
>> 298:             return -1;
>> 299:         }
> 
> I'm skeptical of trying to optimize this without a more thorough performance investigation. We shouldn't add this complexity on a whim.
> 
> I'm more in favor of just dropping the check from the static mismatch method and leaving it at that. (And adding a test as Maurizio mentioned).

I have similar thoughts. This is low-level API. Code using it has more context knowledge and is more fit to do optimisations like that or not, depending if they are worth it. I would want such low level API to do as little checks as possible to accommodate faster common case scenario.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17354#discussion_r1449093606

From eirbjo at openjdk.org  Thu Jan 11 16:49:30 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 11 Jan 2024 16:49:30 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <s75cIa_CJBjOl0qhza78g4llQSruDnC9UURHoWP7HG4=.25aa8b0d-3f35-43c9-be1a-bd97853e8173@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>
 <Yk28MAUo0THuTa083uu-GCAVQiUiQ5RM7N_fXwsERQ4=.d6e51491-ca9a-40fb-b7aa-a8d98d762ec8@github.com>
 <s75cIa_CJBjOl0qhza78g4llQSruDnC9UURHoWP7HG4=.25aa8b0d-3f35-43c9-be1a-bd97853e8173@github.com>
Message-ID: <khugG1Fqiey6BPoUEjhamD-o8J4RsdR3j004Chm5LFs=.46067ff9-6945-4d49-b096-3f7eebff1b0e@github.com>

On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Sounds like a CSR is needed for the behavioral change proposed here.
>
>> Sounds like a CSR is needed for the behavioral change proposed here.
> 
> Thanks for flagging this @jddarcy 
> 
> I'm personally not 100% convinced a CSR is warranted in this case, but I'm of course happy to extend the following into a CSR if you or other reviewer think that's the best way forward:  
> 
> Let's review the intended and unintended behavioral changes in this PR:  
> 
> The _intended_ behavioral change is to extend the set of ZIP entries parsable by `ZipInputStream` to include "small Zip64 entries". Such entries meet the following criteria:
>  
> 1. They are clearly marked as using the Zip64 format, meaning that the LOC's 'compressed size' and 'uncompressed size' fields are set to the "Zip64 magic value" 0xFFFFFFFF and that the LOC's extra field includes a valid _Zip64 Extended Information Field_.
> 2. They use _streaming mode_, meaning that the 'general purpose bit flag' 3 is set, that the Zip64 'Original Size' and 'Compressed Size' are both set to zero and that file data is followed by a 'Data Descriptor' containing the actual size values.
> 3. The Data Descriptor represents the 'compressed size' and 'uncompressed' size fields using 8 byte fields, instead of the regular 4 byte fields.
> 
> These entires are currently not parsable by `ZipInputStream`. Trying to parse them fails with an exception similar to the following:
> 
> 
> java.util.zip.ZipException: invalid entry size (expected 0 but got 6 bytes)
> 	at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:616)
> 
> 
> The _unintended_ behavioral change in this PR is that ZIP entries marked as Zip64, but still having a Data Descriptor using 4 bytes to represent the size fields will now become unparsable. Such entries meet critera 1 and 2 above, but not 3.
> 
> While I have not performed a corpus search, I believe such entries are rare, if they exist at all:
> 
> - They would be in clear violation of the `APPNOTE.txt` spec, which in 4.3.9.2 says  _ZIP64 format MAY be used regardless of the size of a file.  When extracting, if the zip64 extended information extra field is present for the file the compressed and uncompressed sizes will be 8 byte values_
> - The `zipdetails` tool fails to parse such a file, instead reading the two 4-byte numbers into one 8-byte 'compressed size'
> - The file cannot be parsed by external APIs similar to `ZipInputStream`, such as the Python `stream-unzip` module.
> 
> To avoid unintended behavioral changes in the implementation, care has been taken to make the Zip64 extra field validation code robust ...

> @eirbjo, either of the intended or unintended effects of the PR on their own would merit a CSR and this is a case where the inclusive-OR applies so a CSR is definitely needed; thanks.

Thanks Joe!

 A CSR has been proposed and is ready for the first round of feedback: https://bugs.openjdk.org/browse/JDK-8323583

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1887559379

From alanb at openjdk.org  Thu Jan 11 16:50:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 16:50:42 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
 [v2]
In-Reply-To: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
Message-ID: <pcJTUERtP8vMFWJ5IsvpFcYlH3qpvIBOZJAOJ5Ahyh8=.e4f172f9-a0d4-4952-b473-68218fda7fb5@github.com>

> This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Run in othervm mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17353/files
  - new: https://git.openjdk.org/jdk/pull/17353/files/55978a82..4b174603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17353&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17353&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17353/head:pull/17353

PR: https://git.openjdk.org/jdk/pull/17353

From alanb at openjdk.org  Thu Jan 11 16:50:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 16:50:44 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
 [v2]
In-Reply-To: <URdsnXmQf9v2PJQlbe4t81NZRIECVbK0v7daOfnHh2M=.e44b8f94-9e49-4f34-917b-41b04a24f730@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
 <URdsnXmQf9v2PJQlbe4t81NZRIECVbK0v7daOfnHh2M=.e44b8f94-9e49-4f34-917b-41b04a24f730@github.com>
Message-ID: <9htjoAgMHr3VCtmWAP3OCfCyEPsWVC3vC8hh0fqSeGE=.34b6a027-cbf7-4c1f-8814-ff29a67329b4@github.com>

On Thu, 11 Jan 2024 13:21:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run in othervm mode
>
> test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java line 52:
> 
>> 50:         // need at least two carrier threads when main thread is a virtual thread
>> 51:         if (Thread.currentThread().isVirtual()) {
>> 52:             VThreadRunner.ensureParallelism(2);
> 
> Given that this changes the JVM level scheduler's parallelism, should we now use `/othervm` for these tests to prevent this change interfering with other tests?

The ensureParallelism here is to allow the test run on a container configured with a single CPU. I don't think it will impact any other tests that run in the same agent VM, at least I couldn't find any tests where it would create an issue. But you are right that it would be better to restore it or run the test in /othervm mode. The equivalent test in the loom repo does run in /othervm mode as it has to launch with some VM options so we can keep it consistent with that. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17353#discussion_r1449134168

From tprinzing at openjdk.org  Thu Jan 11 17:40:30 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 11 Jan 2024 17:40:30 GMT
Subject: Integrated: 8319571: Update jni/nullCaller/NullCallerTest.java to
 accept flags or mark as flagless
In-Reply-To: <fr4HBv2DrcEGZjPyebY8ztMhSlbvqiF2pqo4cI2zkfE=.00d83315-9e87-415d-b610-886e1175f83d@github.com>
References: <fr4HBv2DrcEGZjPyebY8ztMhSlbvqiF2pqo4cI2zkfE=.00d83315-9e87-415d-b610-886e1175f83d@github.com>
Message-ID: <-ABSnn7wYnlSjonErZ-zSCFPO03oniRk8tKxcO7X3fM=.085f88e7-8a5d-44b8-9cf7-9963f59f4003@github.com>

On Fri, 17 Nov 2023 16:27:44 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Updated to use ProcessTool helper class to run test passing flags.

This pull request has now been integrated.

Changeset: b78896b9
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b78896b9aafcb15f453eaed6e154a5461581407b
Stats:     27 lines in 1 file changed: 1 ins; 21 del; 5 mod

8319571: Update jni/nullCaller/NullCallerTest.java to accept flags or mark as flagless

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/16711

From erikj at openjdk.org  Thu Jan 11 17:52:23 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Jan 2024 17:52:23 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <P1UtBu8Y-P-vN9LIca91jVUvr6RvNRr5BfFDl_tmekQ=.df1e19f9-84dc-403b-9098-970113530538@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
 <2NoIg0vVwzRQQUMAGHm8nMzghFse2GYUj4NcN0XptII=.21965723-5c27-4fcc-b065-901fb4a59b9e@github.com>
 <P1UtBu8Y-P-vN9LIca91jVUvr6RvNRr5BfFDl_tmekQ=.df1e19f9-84dc-403b-9098-970113530538@github.com>
Message-ID: <0OKwM1y969UsLb51y0MTVzZa5KlKiyeYXh5_QRVyCJA=.bba1ff78-37dd-4e38-a199-dd4e45d62e16@github.com>

On Thu, 11 Jan 2024 14:17:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In principle, I think tests should be executed from their corresponding test-support directory. (I think there is some JBS issue for this that's been around for some while.) The rationale is that this is a good directory for any arbitrary output generated from the test, for files that are just dumped in the current directory. (This happens from time to time with tests.)
>> 
>> But if executing from the test image improves the code quality of the tests, I am not going to argue heavily against it.
>
>> In principle, I think tests should be executed from their corresponding test-support directory. (I think there is some JBS issue for this that's been around for some while.) The rationale is that this is a good directory for any arbitrary output generated from the test, for files that are just dumped in the current directory. (This happens from time to time with tests.)
> 
> Magnus does bring up a good point. The root of the test image is a very bad place to accidentally drop arbitrary files when run in our distributed test system, but we don't really run the micros there, at least not like this, do we?

> If the test image dir could be relative to the test-support directory (via a symlink, or knowing that `../test/` always points to the test image) then running from out of there could work. As @erikj79 has figured out then the root issue for me here is that it's not feasible to pass the test image directory as a parameter (since the `@Fork` annotation needs compile-time constants), so if it's possible to configure test-support directories to be in arbitrary places then that would become very fragile.
> 
> None of our JMH tests pollutes the current directory as far as I'm aware, though. And if they did the current situation where the micros are run out of the make directory might arguably be worse.

Fair enough. This isn't worse than the current CWD. The test image dir and the support output dir have no guaranteed relationship relative to each other, so we can't rely any relative path between them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17349#issuecomment-1887672959

From joehw at openjdk.org  Thu Jan 11 18:42:42 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 11 Jan 2024 18:42:42 GMT
Subject: RFR: 8323571: Regression in source resolution process
Message-ID: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>

Fix a regression in the source resolution process where it failed to recognize a custom InputSource when both the public and system IDs are null. The particular issue is fixed at line 1233, the rest of the changes is formatting to make the null-check on InputSource the first.

Test is provided by Marc, thanks Marc! (https://github.com/junit-team/junit5/issues/3594)

XML tests, including the new test, pass with this change.

-------------

Commit messages:
 - 8323571: Regression in source resolution process

Changes: https://git.openjdk.org/jdk/pull/17377/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17377&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323571
  Stats: 355 lines in 4 files changed: 339 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/17377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17377/head:pull/17377

PR: https://git.openjdk.org/jdk/pull/17377

From lancea at openjdk.org  Thu Jan 11 18:55:23 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 11 Jan 2024 18:55:23 GMT
Subject: RFR: 8323571: Regression in source resolution process
In-Reply-To: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
References: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
Message-ID: <mw-rkySuahc1FJLeuhQEMbKDxueKg0sgqY9qJvwTWsM=.fd28a2e9-fb96-4688-98d5-8487450e694e@github.com>

On Thu, 11 Jan 2024 18:36:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a regression in the source resolution process where it failed to recognize a custom InputSource when both the public and system IDs are null. The particular issue is fixed at line 1233, the rest of the changes is formatting to make the null-check on InputSource the first.
> 
> Test is provided by Marc, thanks Marc! (https://github.com/junit-team/junit5/issues/3594)
> 
> XML tests, including the new test, pass with this change.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17377#pullrequestreview-1816320558

From duke at openjdk.org  Thu Jan 11 19:23:22 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 11 Jan 2024 19:23:22 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <tGw8-oOblGEriLtfGjyx3NWJoEUGX9U5BCNn3Qyq78U=.01a8ff07-6ee0-4e37-aeaf-cf34685401dc@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
 <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>
 <AmlJOs7hkqD5rZCH-zPQzEaZOWNmg7VQS2TIJkDEbig=.be56cd27-bebe-49c2-8092-e6b98989daf0@github.com>
 <tGw8-oOblGEriLtfGjyx3NWJoEUGX9U5BCNn3Qyq78U=.01a8ff07-6ee0-4e37-aeaf-cf34685401dc@github.com>
Message-ID: <n46ErejQL-fRok3eBRhr_fhwaw3aKmgi1GOOh1l4u1g=.e4292d14-590c-4d45-a747-04dfb6d42e76@github.com>

On Thu, 11 Jan 2024 09:40:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> tryPresize(int size) is doing and if its size argument is supposed to contain the additional number of elements which will be inserted into the hash map or if it is a hint for the new total size of the hash map

Argument `size` for `tryPresize()` is a hint for the **new total size** of the hash map. If the size is too small compared to the current size of the map, there will be no resizing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1449296202

From jlu at openjdk.org  Thu Jan 11 19:30:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Jan 2024 19:30:09 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v2]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]", decimal pattern: "foo#0.00#baz"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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 four additional commits since the last revision:

 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - account for null locale for SDF through deserialization
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/dfc49edb..1dfc949d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=00-01

  Stats: 3057 lines in 78 files changed: 1931 ins; 706 del; 420 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

PR: https://git.openjdk.org/jdk/pull/17355

From naoto at openjdk.org  Thu Jan 11 19:45:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Jan 2024 19:45:24 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v2]
In-Reply-To: <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>
Message-ID: <DfkwfopSoREFkqMQ6N8dookEIBrMpIW7hnXc9rFgBXA=.b32455fe-20b2-4579-9136-f60ae82f6ee3@github.com>

On Thu, 11 Jan 2024 19:30:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]", decimal pattern: "foo#0.00#baz"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - account for null locale for SDF through deserialization
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - init

I think test cases for these new overridden `toString()` methods would be helpful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17355#issuecomment-1887851029

From naoto at openjdk.org  Thu Jan 11 20:38:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Jan 2024 20:38:29 GMT
Subject: RFR: 8323571: Regression in source resolution process
In-Reply-To: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
References: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
Message-ID: <v2MC3cIffoGcg2qvpRj9eRknQUahdqCISMMpyk5YKVE=.7a315e80-3f24-4ff7-92f5-3925983ddf0a@github.com>

On Thu, 11 Jan 2024 18:36:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a regression in the source resolution process where it failed to recognize a custom InputSource when both the public and system IDs are null. The particular issue is fixed at line 1233, the rest of the changes is formatting to make the null-check on InputSource the first.
> 
> Test is provided by Marc, thanks Marc! (https://github.com/junit-team/junit5/issues/3594)
> 
> XML tests, including the new test, pass with this change.

LGTM. If the file was modified this year, put 2024 in the header

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17377#pullrequestreview-1816602664

From jlu at openjdk.org  Thu Jan 11 21:02:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Jan 2024 21:02:34 GMT
Subject: Integrated: JDK-8322235: Split up and improve LocaleProvidersRun
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <euiNlwTTQio8HqaiIt9ePnguFt_3aTW_9kb8LMYySsE=.bd0e0b3b-72b3-48ba-b2f7-2ff95436e0d0@github.com>

On Wed, 3 Jan 2024 23:30:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - Added comments for each test method

This pull request has now been integrated.

Changeset: 4ea7b364
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579
Stats:     569 lines in 8 files changed: 425 ins; 85 del; 59 mod

8322235: Split up and improve LocaleProvidersRun

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17257

From joehw at openjdk.org  Thu Jan 11 21:03:13 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 11 Jan 2024 21:03:13 GMT
Subject: RFR: 8323571: Regression in source resolution process [v2]
In-Reply-To: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
References: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
Message-ID: <tZNHfs03gZ0O2JEbxoKs-ZfyMDSH1RStTSrUMALGBCE=.40e1b980-797c-4249-9df8-e66d1e07a307@github.com>

> Fix a regression in the source resolution process where it failed to recognize a custom InputSource when both the public and system IDs are null. The particular issue is fixed at line 1233, the rest of the changes is formatting to make the null-check on InputSource the first.
> 
> Test is provided by Marc, thanks Marc! (https://github.com/junit-team/junit5/issues/3594)
> 
> XML tests, including the new test, pass with this change.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17377/files
  - new: https://git.openjdk.org/jdk/pull/17377/files/2eb23440..010c5db8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17377&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17377&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17377/head:pull/17377

PR: https://git.openjdk.org/jdk/pull/17377

From joehw at openjdk.org  Thu Jan 11 21:03:15 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 11 Jan 2024 21:03:15 GMT
Subject: RFR: 8323571: Regression in source resolution process [v2]
In-Reply-To: <v2MC3cIffoGcg2qvpRj9eRknQUahdqCISMMpyk5YKVE=.7a315e80-3f24-4ff7-92f5-3925983ddf0a@github.com>
References: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
 <v2MC3cIffoGcg2qvpRj9eRknQUahdqCISMMpyk5YKVE=.7a315e80-3f24-4ff7-92f5-3925983ddf0a@github.com>
Message-ID: <-XHEiWrIAYSVxObXRwB2KlI-YEcQm6GBY3S3Gtky7Bs=.ffacb941-b022-4b0c-bc11-01fb3b4bdd9e@github.com>

On Thu, 11 Jan 2024 20:35:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> LGTM. If the file was modified this year, put 2024 in the header

Copyright year fixed. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17377#issuecomment-1887951201

From prappo at openjdk.org  Thu Jan 11 21:52:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 11 Jan 2024 21:52:35 GMT
Subject: Integrated: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <zODXHjRUec47GFPmSkjjI8pi6qjXblUSXhl1q3W1xRE=.a2fbf89f-33cb-457c-a9a5-b9b243f5da11@github.com>

On Fri, 23 Jun 2023 17:27:00 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.

This pull request has now been integrated.

Changeset: 49e61213
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49e61213474b846fd081e890e5abfbbbb9b79e3c
Stats:     527 lines in 6 files changed: 500 ins; 16 del; 11 mod

8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger

Reviewed-by: rriggs, redestad, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/14630

From asemenyuk at openjdk.org  Thu Jan 11 22:16:58 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 11 Jan 2024 22:16:58 GMT
Subject: RFR: 8322799: Test JPKG003-013: ServiceTest fails because the user
 cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit
 Arm (aarch64)
Message-ID: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>

Change the full path of a unit file passed to `systemctl enable` command to the unit file name. This prevents the command from creating a symlink in `/etc/systemd/system/` directory

-------------

Commit messages:
 - empty
 - Merge branch 'master' into JDK-8322799
 - 8322799: Test JPKG003-013: ServiceTest fails because the user cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit Arm (aarch64)
 - Make sure worker thread terminates before the main thread does.
 - 8294699: Launcher causes lingering busy cursor

Changes: https://git.openjdk.org/jdk/pull/17376/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17376&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322799
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17376.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17376/head:pull/17376

PR: https://git.openjdk.org/jdk/pull/17376

From asemenyuk at openjdk.org  Thu Jan 11 22:16:58 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 11 Jan 2024 22:16:58 GMT
Subject: RFR: 8322799: Test JPKG003-013: ServiceTest fails because the user
 cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit
 Arm (aarch64)
In-Reply-To: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
References: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
Message-ID: <vEUZcYGt4bj80GHTbL0AoQ5b0s7UFXVlTDRoKQj4TZQ=.8e13b870-184a-4b69-aca2-8d49f00b033a@github.com>

On Thu, 11 Jan 2024 18:19:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change the full path of a unit file passed to `systemctl enable` command to the unit file name. This prevents the command from creating a symlink in `/etc/systemd/system/` directory

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17376#issuecomment-1887787798

From almatvee at openjdk.org  Thu Jan 11 22:16:59 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 11 Jan 2024 22:16:59 GMT
Subject: RFR: 8322799: Test JPKG003-013: ServiceTest fails because the user
 cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit
 Arm (aarch64)
In-Reply-To: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
References: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
Message-ID: <1_xXRCmBywMlr9ycMFljAXfbnEp5DMrK6rk_Ze-wGoM=.fa25f4ec-118c-4b02-b5c4-fdd5742734b8@github.com>

On Thu, 11 Jan 2024 18:19:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change the full path of a unit file passed to `systemctl enable` command to the unit file name. This prevents the command from creating a symlink in `/etc/systemd/system/` directory

Fix looks good. I will approve once "Integration blocker" issue is resolved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17376#issuecomment-1887841042

From joehw at openjdk.org  Thu Jan 11 22:41:33 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 11 Jan 2024 22:41:33 GMT
Subject: Integrated: 8323571: Regression in source resolution process
In-Reply-To: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
References: <W-IOn6wTdDuZaJk34I4Bw8DatUhEwB5vdOk0zWE71Ug=.075c1161-4fc9-4c0f-a5ae-1c2a43a60418@github.com>
Message-ID: <mWxoK9OKpy-g5LElFIRsBP7cSNO7Na79oRDhRXmPbOo=.b3366caf-51ea-439f-a0c2-4ddf73b68901@github.com>

On Thu, 11 Jan 2024 18:36:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a regression in the source resolution process where it failed to recognize a custom InputSource when both the public and system IDs are null. The particular issue is fixed at line 1233, the rest of the changes is formatting to make the null-check on InputSource the first.
> 
> Test is provided by Marc, thanks Marc! (https://github.com/junit-team/junit5/issues/3594)
> 
> XML tests, including the new test, pass with this change.

This pull request has now been integrated.

Changeset: e4389d8d
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4389d8dc224419b8c1ee08e9f2dea0f103c6845
Stats:     357 lines in 4 files changed: 339 ins; 0 del; 18 mod

8323571: Regression in source resolution process

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17377

From almatvee at openjdk.org  Thu Jan 11 22:44:18 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 11 Jan 2024 22:44:18 GMT
Subject: RFR: 8322799: Test JPKG003-013: ServiceTest fails because the user
 cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit
 Arm (aarch64)
In-Reply-To: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
References: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
Message-ID: <79c6kPeh2XcDYYWhjZ4HASu8EOE-NZmaPUEyRUqRFcQ=.d76324de-4704-4311-b806-53a182726466@github.com>

On Thu, 11 Jan 2024 18:19:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change the full path of a unit file passed to `systemctl enable` command to the unit file name. This prevents the command from creating a symlink in `/etc/systemd/system/` directory

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17376#pullrequestreview-1816945852

From asemenyuk at openjdk.org  Thu Jan 11 23:01:31 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 11 Jan 2024 23:01:31 GMT
Subject: Integrated: 8322799: Test JPKG003-013: ServiceTest fails because the
 user cannot uninstall the "servicetest" package on OEL 9.2 x64 and
 OEL 9.2 64-bit Arm (aarch64)
In-Reply-To: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
References: <sErzrtMkYsqlV3W-OYyi_0ABBJEFNOx-ZpWsM-Jtn70=.7c90f046-a28b-4197-a763-5152a6b387f8@github.com>
Message-ID: <CblNORTP3TzAeqQ5CbgvzLA9gsnslgtZKv-f2pgldLw=.124598d5-586c-4fcf-8046-67ff3188f094@github.com>

On Thu, 11 Jan 2024 18:19:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change the full path of a unit file passed to `systemctl enable` command to the unit file name. This prevents the command from creating a symlink in `/etc/systemd/system/` directory

This pull request has now been integrated.

Changeset: 8e12053e
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e12053e0352a26ecd7f2b9bc298ddb8fb4bb61b
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8322799: Test JPKG003-013: ServiceTest fails because the user cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit Arm (aarch64)

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/17376

From joehw at openjdk.org  Thu Jan 11 23:05:29 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 11 Jan 2024 23:05:29 GMT
Subject: [jdk22] RFR: 8323571: Regression in source resolution process
Message-ID: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>

Backport to fix the regression introduced in JDK 22.

-------------

Commit messages:
 - Backport e4389d8dc224419b8c1ee08e9f2dea0f103c6845

Changes: https://git.openjdk.org/jdk22/pull/63/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=63&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323571
  Stats: 357 lines in 4 files changed: 339 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk22/pull/63.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/63/head:pull/63

PR: https://git.openjdk.org/jdk22/pull/63

From sgibbons at openjdk.org  Thu Jan 11 23:06:32 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Jan 2024 23:06:32 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
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: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'openjdk:master' into indexof
 - Merge branch 'openjdk:master' into indexof
 - Addressing review comments.
 - Fix for JDK-8321599
 - Support UU IndexOf
 - Only use optimization when EnableX86ECoreOpts is true
 - Fix whitespace
 - Merge branch 'openjdk:master' into indexof
 - Comments; added exhaustive-ish test
 - Subtracting 0x10 twice.
 - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

-------------

Changes: https://git.openjdk.org/jdk/pull/16753/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=06
  Stats: 3060 lines in 14 files changed: 2918 ins; 7 del; 135 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 naoto at openjdk.org  Thu Jan 11 23:22:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Jan 2024 23:22:23 GMT
Subject: [jdk22] RFR: 8323571: Regression in source resolution process
In-Reply-To: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>
References: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>
Message-ID: <gyHuS_NVVESJWag4Dub_oqzLfkaxrIHk9aGRTdOpQdY=.7b3673c3-e25c-4ae4-a6a9-5b62964498e6@github.com>

On Thu, 11 Jan 2024 22:56:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Backport to fix the regression introduced in JDK 22.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/63#pullrequestreview-1817006707

From iris at openjdk.org  Thu Jan 11 23:40:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 11 Jan 2024 23:40:23 GMT
Subject: [jdk22] RFR: 8323571: Regression in source resolution process
In-Reply-To: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>
References: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>
Message-ID: <1C6KT-zxsmlIMHlbIWTSIRGgIptXcuaEjscJelPuvxA=.6c8bb7e6-932b-45a0-87ed-905a63a4ff9c@github.com>

On Thu, 11 Jan 2024 22:56:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Backport to fix the regression introduced in JDK 22.

Verified changes same as those in main-line.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/63#pullrequestreview-1817021441

From serb at openjdk.org  Fri Jan 12 01:01:45 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Jan 2024 01:01:45 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
Message-ID: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>

SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

-------------

Commit messages:
 - 8323562: SaslInputStream.read() may return wrong value

Changes: https://git.openjdk.org/jdk/pull/17365/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17365&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323562
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17365/head:pull/17365

PR: https://git.openjdk.org/jdk/pull/17365

From serb at openjdk.org  Fri Jan 12 01:01:46 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Jan 2024 01:01:46 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
Message-ID: <lrtldA1oZeY7XdqvkZM5BVD7ED5-ICw7G3iSTEo8doI=.64612454-0355-4fc7-8cec-287a073b4045@github.com>

On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

I'll wait until GA will be fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1888222498

From lmesnik at openjdk.org  Fri Jan 12 01:13:23 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 Jan 2024 01:13:23 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v3]
In-Reply-To: <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
 <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
Message-ID: <yl5QbZE3gceJkEaIvaRClHZ-VPMZkPI1jQtOzLw4Sic=.67c79c41-4487-4b15-9add-85e2ea6e0179@github.com>

On Fri, 5 Jan 2024 09:07:57 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 with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8320699_OutputAnalyzer_progress_logging
>  - Update OutputBuffer.java copyright years
>  - 8320699: Add parameter to skip progress logging of OutputAnalyzer

Needed to update copyrights now.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16807#pullrequestreview-1817096686

From joehw at openjdk.org  Fri Jan 12 01:49:30 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 12 Jan 2024 01:49:30 GMT
Subject: [jdk22] Integrated: 8323571: Regression in source resolution process
In-Reply-To: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>
References: <7J_RyLFt4zqF6hQLMiLObF0o621wrThso1erMo39XIA=.29cfce7f-acd6-48e7-9eb9-255f9bf9c4dc@github.com>
Message-ID: <zRWvln53InXfxmmFU4cKvFic6y2VzO3TFVygIgWpsZI=.9450abc5-2972-4a58-9f5b-6f3d17130bbc@github.com>

On Thu, 11 Jan 2024 22:56:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Backport to fix the regression introduced in JDK 22.

This pull request has now been integrated.

Changeset: 46f1df38
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/46f1df38a0f972333d7ff93a00c7eb6b14d3dfb9
Stats:     357 lines in 4 files changed: 339 ins; 0 del; 18 mod

8323571: Regression in source resolution process

Reviewed-by: naoto, iris
Backport-of: e4389d8dc224419b8c1ee08e9f2dea0f103c6845

-------------

PR: https://git.openjdk.org/jdk22/pull/63

From jpai at openjdk.org  Fri Jan 12 02:02:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Jan 2024 02:02:19 GMT
Subject: RFR: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
 [v2]
In-Reply-To: <pcJTUERtP8vMFWJ5IsvpFcYlH3qpvIBOZJAOJ5Ahyh8=.e4f172f9-a0d4-4952-b473-68218fda7fb5@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
 <pcJTUERtP8vMFWJ5IsvpFcYlH3qpvIBOZJAOJ5Ahyh8=.e4f172f9-a0d4-4952-b473-68218fda7fb5@github.com>
Message-ID: <i6M33XroNty3Uxqu_anYTXghjobyT51y565Z6Bz6J2Q=.072f94c4-4596-498f-ba78-7d616287d27e@github.com>

On Thu, 11 Jan 2024 16:50:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run in othervm mode

Thank you Alan, the changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17353#pullrequestreview-1817235395

From duke at openjdk.org  Fri Jan 12 03:37:27 2024
From: duke at openjdk.org (sendaoYan)
Date: Fri, 12 Jan 2024 03:37:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
Message-ID: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>

Reviewed-by: Yi Yang

-------------

Commit messages:
 - 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

Changes: https://git.openjdk.org/jdk/pull/17386/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17386&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323640
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17386/head:pull/17386

PR: https://git.openjdk.org/jdk/pull/17386

From cutefish.yx at gmail.com  Fri Jan 12 06:00:33 2024
From: cutefish.yx at gmail.com (Xiao Yu)
Date: Thu, 11 Jan 2024 22:00:33 -0800
Subject: The common ForkJoinPool does not have any ForkJoinWorkerThread while
 tasks are submitted to the queue
Message-ID: <CAPyYzD6wixKQW7q=NUKbQkO_FTJyia-Z+CHeCvC4mRKHxgqVkA@mail.gmail.com>

Hello Core Libs Dev Team,

This is my first time posting here. Please let me know if there are any
conventions I should follow.

I am writing in the hope to get some help to understand a state of the
ForkJoinPool that we observed. We have encountered a case where there were
tasks
inside the queue of the ForkJoinPool, but there was no ForkJoinWorkerThread
to
execute them. I am wondering if such state is expected of the ForkJoinPool
and
hopefully I could get some suggestion to understand how our system entered
such
state.

Here is the full background. One of our process experienced an OOME and a
heap
dump was obtained. We know there was a concurrent issue of our system
happening
on some other machines such that network failure and retries occurred in
this
process at the same time. Upon analyzing the heap dump, we observed a lot of
our network connection handlers being frequently created and terminated
which
is expected due to the network failure and retry attempts mentioned above.
However, those terminated handlers are not being GC'ed because of there were
references to tasks submitted to the ForkJoinPool during the connection
attempts. The tasks stayed in the queue until OOME happened as there is no
threads to execute them.

>From both the heap dump and the thread dump, it seems there was no
ForkJoinWorkerThread which, from my understanding, is the worker thread
object
to execute those tasks. Looking at the ForkJoinPool, I noticed that the ctl
field was 9223372032559808512 or 0x7fff ffff 00000000. Is this a valid ctl
state? From the code, this ctl field (together with mode = 1) seems to mean
a released thread count of 32768 and a total thread count of 0 which seems
weird to me because with my current understanding, the total thread count
should be larger than the released thread count. This also seems to cause
the
signalWork method not creating any new thread, since ctl is positive which
seems to reflect the fact that new threads are not being created while there
were tasks in the queue. Perhaps there are some exceptions that we should
catch
but did not pay attention to which caused this state?

Currently, we do not know how to reproduce this issue. Sorry about that. The
heap dump is about 1G in size and therefore, it is not very convenient to
attach in the email, but here are some information I collected from the heap
dump.

Summary info:

``````
System : Linux(5.4.17-2136.325.5.1.el7uek.x86_64)
Architecture: amd64 64bit
Java Version: 17.0.4.1 2022-08-18 LTS
Java Name: Java HotSpot(TM) 64-Bit Server VM (17.0.4.1+1-LTS-2, mixed mode,
sharing)
Java Vendor: Oracle Corporation
``````

ForkJoinPool#common states:

``````
ctl: 9223372032559808512
saturate: null
ueh: null
factory:
java.util.concurrent.ForkJoinPool$DefaultCommonPoolForkJoinWorkerThreadFactory
workerNamePrefix: null
termination: null
registrationLock: java.util.concurrent.locks.ReentrantLock
queues: java.util.concurrent.ForkJoinPool$WorkQueue[]
mode: 1
bounds: 16777216
threadIds: 32768
scanRover: 0
stealCount: 10912
keepAlive: 60000
``````

ForkJoinPool#common#queue[0] states:

``````
nsteals: 0
source: 0
top: 32304
owner: null
array: java.util.concurrent.ForkJoinTask[]
base: 10912
config: 2027939556
stackPred: 0
phase: -1
``````

The thread dump is attached.

Please let me know if you need anything else.


Xiao Yu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240111/09f04def/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread.dump
Type: application/octet-stream
Size: 227080 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240111/09f04def/thread-0001.dump>

From alanb at openjdk.org  Fri Jan 12 07:25:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jan 2024 07:25:19 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
Message-ID: <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>

On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

Just curious if this was found by inspection or when debugging some issue with LDAP authentication? Asking on whether it is feasible or not to have more tests in this area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1888555729

From serb at openjdk.org  Fri Jan 12 07:35:20 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Jan 2024 07:35:20 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
 <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>
Message-ID: <gF74tvhZgt8K8Sw58SRFn-dDrSRS7GNgR94rFp22BXw=.1af1403a-fb1c-4c79-a3b9-af73260a0306@github.com>

On Fri, 12 Jan 2024 07:22:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Just curious if this was found by inspection or when debugging some issue with LDAP authentication? Asking on whether it is feasible or not to have more tests in this area.

It was found by the code inspection.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1888567273

From darcy at openjdk.org  Fri Jan 12 07:38:12 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 07:38:12 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier [v3]
In-Reply-To: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
Message-ID: <0Yn_cuirspDc9gpJsMeFe3bDKtIwvsUCwdW9snv91jI=.37c33f82-9d2d-4baa-91d5-54f919765068@github.com>

> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Refine wording per review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17338/files
  - new: https://git.openjdk.org/jdk/pull/17338/files/e5816889..cc67f321

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17338&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17338&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17338/head:pull/17338

PR: https://git.openjdk.org/jdk/pull/17338

From alanb at openjdk.org  Fri Jan 12 08:36:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jan 2024 08:36:25 GMT
Subject: Integrated: 8323296:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out
In-Reply-To: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
References: <FN6wl-wI0lXZ2C6Dly_Oxk_HBeQnCOeYYbW9R6DyU7U=.566533f7-0855-4e67-b71f-0f59c953c978@github.com>
Message-ID: <26JVNgRp9dMbqz61P_4_EWPNr2dHc1ncPrqYhqfFaso=.1ebde847-8edc-4c1f-adff-1c79986f775d@github.com>

On Wed, 10 Jan 2024 20:25:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test was recently dialled down via JDK-8323002 but it still makes slow progress on some test machines, esp. macox-x64-debug builds. The issue is that the sampling of the target thread is skewed towards the unmounted case so the target thread is disabled from being scheduled and doesn't make progress. The test is re-worked to use a barrier so that the main thread and target virtual thread run in lock step. This allows the virtual thread to make progress at each iteration and also increases the chances of sampling the stack trace at around the time that the target thread transitions from being unmounted (due to the Thread.yield) and parking while pinned.

This pull request has now been integrated.

Changeset: e72723dc
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e72723dc5c61292303a992319794e5edb28a4e98
Stats:     53 lines in 1 file changed: 47 ins; 0 del; 6 mod

8323296: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/17353

From simonis at openjdk.org  Fri Jan 12 08:54:22 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 12 Jan 2024 08:54:22 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <n46ErejQL-fRok3eBRhr_fhwaw3aKmgi1GOOh1l4u1g=.e4292d14-590c-4d45-a747-04dfb6d42e76@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
 <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>
 <AmlJOs7hkqD5rZCH-zPQzEaZOWNmg7VQS2TIJkDEbig=.be56cd27-bebe-49c2-8092-e6b98989daf0@github.com>
 <tGw8-oOblGEriLtfGjyx3NWJoEUGX9U5BCNn3Qyq78U=.01a8ff07-6ee0-4e37-aeaf-cf34685401dc@github.com>
 <n46ErejQL-fRok3eBRhr_fhwaw3aKmgi1GOOh1l4u1g=.e4292d14-590c-4d45-a747-04dfb6d42e76@github.com>
Message-ID: <16gxaKYHEH5R2fmIJmlPldL8c7LHxAiRV2mMnxGE2ZY=.44794184-2ae8-4554-a1db-4e1e1484dd08@github.com>

On Thu, 11 Jan 2024 19:21:00 GMT, Joshua Cao <duke at openjdk.org> wrote:

>>> We don't need to compute max() here. [tryPresize()](https://github.com/openjdk/jdk/blob/8a4dc79e1a40e7115e2971af81623b6b0368f41c/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2397) does that already.
>> 
>> The code you reference is only executed if `table == null` but in this case we know it is not `null` because we only call `tryPresize()` if `table != null`.
>> 
>> In general, it's hard fro me to understand what `tryPresize(int size)` is doing and if its `size` argument is supposed to contain the additional number of elements which will be inserted into the hash map or if it is a hint for the new total size of the hash map. Can you explain?
>
>> tryPresize(int size) is doing and if its size argument is supposed to contain the additional number of elements which will be inserted into the hash map or if it is a hint for the new total size of the hash map
> 
> Argument `size` for `tryPresize()` is a hint for the **new total size** of the hash map. If the size is too small compared to the current size of the map, there will be no resizing.

Thanks. In that case, calling `tryPresize()` with `size < this.size()` doesn't make sense and we should call it with `this.size() + m.size()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1450063503

From stefank at openjdk.org  Fri Jan 12 09:08:26 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Jan 2024 09:08:26 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v3]
In-Reply-To: <yl5QbZE3gceJkEaIvaRClHZ-VPMZkPI1jQtOzLw4Sic=.67c79c41-4487-4b15-9add-85e2ea6e0179@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
 <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
 <yl5QbZE3gceJkEaIvaRClHZ-VPMZkPI1jQtOzLw4Sic=.67c79c41-4487-4b15-9add-85e2ea6e0179@github.com>
Message-ID: <2r7Wm5bucnYz2HFlIUhTwsZ2UX25lBvo5PEdToB4r2I=.b1d71e17-0ef6-4c96-ad87-7c616a864c56@github.com>

On Fri, 12 Jan 2024 01:10:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Needed to update copyrights now.

Even when the code was written in 2023?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1888699636

From redestad at openjdk.org  Fri Jan 12 10:03:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Jan 2024 10:03:27 GMT
Subject: RFR: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <0OKwM1y969UsLb51y0MTVzZa5KlKiyeYXh5_QRVyCJA=.bba1ff78-37dd-4e38-a199-dd4e45d62e16@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
 <2NoIg0vVwzRQQUMAGHm8nMzghFse2GYUj4NcN0XptII=.21965723-5c27-4fcc-b065-901fb4a59b9e@github.com>
 <P1UtBu8Y-P-vN9LIca91jVUvr6RvNRr5BfFDl_tmekQ=.df1e19f9-84dc-403b-9098-970113530538@github.com>
 <0OKwM1y969UsLb51y0MTVzZa5KlKiyeYXh5_QRVyCJA=.bba1ff78-37dd-4e38-a199-dd4e45d62e16@github.com>
Message-ID: <Zh-MFFUU52YhOyja-Co0Ph1bw0IzLa2QH6tQts45s-E=.7b7469ea-b2d5-47c8-a527-b4f26694c1b3@github.com>

On Thu, 11 Jan 2024 17:49:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Fair enough. This isn't worse than the current CWD. The test image dir and the support output dir have no guaranteed relationship relative to each other, so we can't rely any relative path between them.

Thanks! Perhaps we can improve things down the line so that it'd be possible or even easy to run out of test-support. Using the JMH java API is doable to achieve this, but then we'd need to change the way we run micros in some rather convoluted ways.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17349#issuecomment-1888786622

From redestad at openjdk.org  Fri Jan 12 10:03:29 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Jan 2024 10:03:29 GMT
Subject: Integrated: 8323529: Relativize test image dependencies in
 microbenchmarks
In-Reply-To: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
References: <GYumt4cvCFMVTyGNnwABAydNuJk3klyUi5BLUZP40o4=.998c8d22-4795-4f13-ba06-9eb0ce2bf3d2@github.com>
Message-ID: <yU49ynHXxpVVA1ro2PQ4A1Ks-e-v6AnafBrbB-w_4Fs=.819ad539-0538-4fc7-8d9a-9d84bb0c6a99@github.com>

On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> JMH microbenchmarks may have dependencies on artifacts in the test image outside of the benchmarks.jar. This includes native libraries (built into `$TEST_IMAGE/micro/native`) and may soon include other test libraries like wb.jar (built into `$TEST_IMAGE/lib-test/`)
> 
> By moving execution to the test image root (currently we run out of the `make` directory) we can make do with relative paths, which means benchmark can supply a build-time constant flag themselves rather than have the test runner provide it for you. And needing to be explicit about external dependencies is good, I think.
> 
> Taken together this makes the benchmarks.jar more self-contained and simpler to run: all you need is to run `java -jar micro/benchmarks.jar` from the test image root.
> 
> This patch also drive-by fixes some lang.foreign tests that were printing warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag.

This pull request has now been integrated.

Changeset: 3e19bf88
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e19bf88d5b51fe10c183f930b99bce961a368c1
Stats:     21 lines in 17 files changed: 5 ins; 0 del; 16 mod

8323529: Relativize test image dependencies in microbenchmarks

Reviewed-by: mcimadamore, jvernee, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/17349

From chegar at openjdk.org  Fri Jan 12 10:59:29 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 10:59:29 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call overridable
 offer
Message-ID: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>

Update LinkedTransferQueue add and put methods to not call overridable.

-------------

Commit messages:
 - Update LinkedTransferQueue add and put methods to not call overridable offer

Changes: https://git.openjdk.org/jdk/pull/17393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323659
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From alanb at openjdk.org  Fri Jan 12 11:05:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jan 2024 11:05:19 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <YSH3sMWoOuM_I5YtXAWQAQ9V4GH2wc6qkz1T_b3wSng=.d7ef8fde-7c55-4c01-84f7-49fba3f545f1@github.com>

On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Update LinkedTransferQueue add and put methods to not call overridable.

This feels more like a hazard when extending to override behavior. I think it would be useful to provide a summary on what the override wants to do, maybe there are better ways to customise by wrapping the LTQ rather than subclassing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888889220

From prappo at openjdk.org  Fri Jan 12 11:14:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 12 Jan 2024 11:14:18 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>

On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Update LinkedTransferQueue add and put methods to not call overridable.

A process-related comment: this PR is against mainline, but the issue's Fix Version/s is 22. This will create a bit of a mess if integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888895253

From chegar at openjdk.org  Fri Jan 12 11:14:19 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 11:14:19 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <YSH3sMWoOuM_I5YtXAWQAQ9V4GH2wc6qkz1T_b3wSng=.d7ef8fde-7c55-4c01-84f7-49fba3f545f1@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <YSH3sMWoOuM_I5YtXAWQAQ9V4GH2wc6qkz1T_b3wSng=.d7ef8fde-7c55-4c01-84f7-49fba3f545f1@github.com>
Message-ID: <0bVu1nuX_yRJE9bNCvKi4umfYA--ZVZxNuNR2ec3kJk=.216e7f71-4aa5-4090-a9a5-b3d5b47730a6@github.com>

On Fri, 12 Jan 2024 11:03:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This feels more like a hazard when extending to override behavior. 

Yeah, this is certainly a potential issue with any subclass-able class. I remember seeing similar before in other areas too.

> I think it would be useful to provide a summary on what the override wants to do, maybe there are better ways to customise by wrapping the LTQ rather than subclassing.

Yeah, and we can likely refactor our code to workaround this change in JDK 22.  I added a summary and reproducer in the JIRA, which should help. I'll try to explain a little here.  The crux of what the code is attempting to do is to scale the executor to max pool size by refusing tasks if there is the pool is less than the given max, then later intercepting rejections and putting the task on the queue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888898399

From chegar at openjdk.org  Fri Jan 12 11:14:21 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 11:14:21 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>
Message-ID: <WWjdSTkIWyyoADLe5XRCJGYy7Xji1Yb_2KHSutUpsyk=.d857d0ce-52fe-4be2-99bd-0d7b67374643@github.com>

On Fri, 12 Jan 2024 11:07:17 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> A process-related comment: this PR is against mainline, but the issue's Fix Version/s is 22. This will create a bit of a mess if integrated.

Thanks for the reminder Pavel.  If accepted, then the change will be applicable to 23, 22, and 21. 0.2.  I'll fix up and retarget the appropriate branches, repos, once we agree a way forward.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888901110

From jvernee at openjdk.org  Fri Jan 12 11:23:22 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 12 Jan 2024 11:23:22 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v2]
In-Reply-To: <-gjTiaVmyJT28RbwaFpTi1rj-7RMaUwAOc382xheR8k=.96c62e45-320e-4fd4-8d4c-73f3553eba9b@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <-gjTiaVmyJT28RbwaFpTi1rj-7RMaUwAOc382xheR8k=.96c62e45-320e-4fd4-8d4c-73f3553eba9b@github.com>
Message-ID: <LR8H59kcMDdvIYiNhgwtmZdkrfYrI1XPlpPlZmteeog=.09e3a2d6-7b31-4f86-a247-f1fa15364f45@github.com>

On Thu, 11 Jan 2024 07:59:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
>> 
>> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move and change text on zeroing out

src/java.base/share/classes/java/lang/foreign/Arena.java line 215:

> 213:  * {@linkplain #ofConfined()} and, {@linkplain #ofShared()} will return segments
> 214:  * that are zeroed out when invoking {@linkplain Arena#allocate(long, long) allocate()}.
> 215:  *

I'd expect to find this in the javadoc of each factory method (not in an implSpec). The note says something about those particular methods, not about the Arena type as a whole.

I also think "zero intialized" sounds a bit more professional than "zeroed out". I suggest the following phrasing: 

    Memory segments {@linkPlain #allocate(long, long) allocated} by the returned arena are zero initialized

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1450270020

From chegar at openjdk.org  Fri Jan 12 11:25:22 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 11:25:22 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <WWjdSTkIWyyoADLe5XRCJGYy7Xji1Yb_2KHSutUpsyk=.d857d0ce-52fe-4be2-99bd-0d7b67374643@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>
 <WWjdSTkIWyyoADLe5XRCJGYy7Xji1Yb_2KHSutUpsyk=.d857d0ce-52fe-4be2-99bd-0d7b67374643@github.com>
Message-ID: <36PgGi1eMNgF3raAg-KzhJK0pjyQ7faGETzGyYiHhkg=.3ca8729f-5c25-4f77-9680-d9dd12fba849@github.com>

On Fri, 12 Jan 2024 11:11:51 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> this PR is against mainline, but the issue's Fix Version/s is 22.

I updated the fix version in JIRA, and followed the process as outlined in https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888916748

From shade at openjdk.org  Fri Jan 12 11:46:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 12 Jan 2024 11:46:19 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
Message-ID: <Imnl32GJK-NmOSNjhEj2Avb3RdFB4fMDgDdB4VpbsG8=.33f74bc7-27dd-4316-925f-8a34aff97051@github.com>

On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

Looks fine. I think the common style is to use capitalized `0xFF`, but that one is not enforced consistently. This will do as well.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17365#pullrequestreview-1818007975

From shade at openjdk.org  Fri Jan 12 11:46:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 12 Jan 2024 11:46:21 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <gF74tvhZgt8K8Sw58SRFn-dDrSRS7GNgR94rFp22BXw=.1af1403a-fb1c-4c79-a3b9-af73260a0306@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
 <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>
 <gF74tvhZgt8K8Sw58SRFn-dDrSRS7GNgR94rFp22BXw=.1af1403a-fb1c-4c79-a3b9-af73260a0306@github.com>
Message-ID: <sW_mS9d2bWM8tjdwaq-DwbZBeEuAMDSF-LNG3RpjWvc=.8f8b7333-3310-4a4d-9e32-31bb50f97e8b@github.com>

On Fri, 12 Jan 2024 07:33:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just curious if this was found by inspection or when debugging some issue with LDAP authentication? Asking on whether it is feasible or not to have more tests in this area.

No need, that one is an easy target for static analyzers. This bug was found by one :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1888946629

From vklang at openjdk.org  Fri Jan 12 11:54:19 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 12 Jan 2024 11:54:19 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <36PgGi1eMNgF3raAg-KzhJK0pjyQ7faGETzGyYiHhkg=.3ca8729f-5c25-4f77-9680-d9dd12fba849@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>
 <WWjdSTkIWyyoADLe5XRCJGYy7Xji1Yb_2KHSutUpsyk=.d857d0ce-52fe-4be2-99bd-0d7b67374643@github.com>
 <36PgGi1eMNgF3raAg-KzhJK0pjyQ7faGETzGyYiHhkg=.3ca8729f-5c25-4f77-9680-d9dd12fba849@github.com>
Message-ID: <ljE0RDe0qRzhd-mCGu2jpsZpW_EsccxFxsLyXwvOHZ0=.1e859fe5-ca5b-473d-812b-1242350740e6@github.com>

On Fri, 12 Jan 2024 11:22:13 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>>> A process-related comment: this PR is against mainline, but the issue's Fix Version/s is 22. This will create a bit of a mess if integrated.
>> 
>> Thanks for the reminder Pavel.  If accepted, then the change will be applicable to 23, 22, and 21. 0.2.  I'll fix up and retarget the appropriate branches, repos, once we agree a way forward.
>
>> this PR is against mainline, but the issue's Fix Version/s is 22.
> 
> I updated the fix version in JIRA, and followed the process as outlined in https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html

@ChrisHegarty My 2??this change could impact existing classes which have extended LTQ and knowingly, or unknowingly, presume that add and put delegate to offer, which would (silently) break those classes when running on a newer JDK (presuming this change gets merged).

I think the change is in principle correct, with that said, I want to make sure that the change is worth the potential compatibility risk (if any).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1888966783

From alanb at openjdk.org  Fri Jan 12 11:56:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jan 2024 11:56:18 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <sW_mS9d2bWM8tjdwaq-DwbZBeEuAMDSF-LNG3RpjWvc=.8f8b7333-3310-4a4d-9e32-31bb50f97e8b@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
 <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>
 <gF74tvhZgt8K8Sw58SRFn-dDrSRS7GNgR94rFp22BXw=.1af1403a-fb1c-4c79-a3b9-af73260a0306@github.com>
 <sW_mS9d2bWM8tjdwaq-DwbZBeEuAMDSF-LNG3RpjWvc=.8f8b7333-3310-4a4d-9e32-31bb50f97e8b@github.com>
Message-ID: <EK0cgYdMcPk_7CkFi3inowJMertC00C3DpMq7zbxYXY=.7babb45d-57cc-4c6b-8ff6-32d85d1f2f07@github.com>

On Fri, 12 Jan 2024 11:43:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> No need, that one is an easy target for static analyzers. This bug was found by one :)

I think this one will require digging into whether the no-arg read is used in the authentication or not. It might not be, in which case it's not testable with something that emulates LDAPv3.  However if it is used then we should have fuzzing or other tests to exercise it. I'm not saying it should be part of this PR but finding a 15+ year issue in authentication code is concerning so will need follow-up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1888973627

From jpai at openjdk.org  Fri Jan 12 12:05:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Jan 2024 12:05:20 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
Message-ID: <yPgn8cBVwjll35EGtXpfNWlETI2HDjnQlK5wWKJtnmQ=.ad2d06aa-1235-4c53-a692-c3b3a3222df8@github.com>

On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

src/java.naming/share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java line 83:

> 81:             return inBuf[0] & 0xff;
> 82:         } else {
> 83:             return -1;

As a separate follow up, even this else block might need some review on whether `count` can practically be 0 here and if so whether it's OK to return -1 (implying EOF) in such cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17365#discussion_r1450341455

From chegar at openjdk.org  Fri Jan 12 12:18:19 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 12:18:19 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <36PgGi1eMNgF3raAg-KzhJK0pjyQ7faGETzGyYiHhkg=.3ca8729f-5c25-4f77-9680-d9dd12fba849@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>
 <WWjdSTkIWyyoADLe5XRCJGYy7Xji1Yb_2KHSutUpsyk=.d857d0ce-52fe-4be2-99bd-0d7b67374643@github.com>
 <36PgGi1eMNgF3raAg-KzhJK0pjyQ7faGETzGyYiHhkg=.3ca8729f-5c25-4f77-9680-d9dd12fba849@github.com>
Message-ID: <M2mFM05i_NG-UInXDzSeaw4AusHi4v6FU13PueZ9nrg=.76dd3a7e-929b-47eb-9d8d-226e2ec654cb@github.com>

On Fri, 12 Jan 2024 11:22:13 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>>> A process-related comment: this PR is against mainline, but the issue's Fix Version/s is 22. This will create a bit of a mess if integrated.
>> 
>> Thanks for the reminder Pavel.  If accepted, then the change will be applicable to 23, 22, and 21. 0.2.  I'll fix up and retarget the appropriate branches, repos, once we agree a way forward.
>
>> this PR is against mainline, but the issue's Fix Version/s is 22.
> 
> I updated the fix version in JIRA, and followed the process as outlined in https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html

> @ChrisHegarty My 2??this change could impact existing classes which have extended LTQ and knowingly, or unknowingly, presume that add and put delegate to offer, which would (silently) break those classes when running on a newer JDK (presuming this change gets merged).
> 
> I think the change is in principle correct, with that said, I want to make sure that the change is worth the potential compatibility risk (if any).

Hi @viktorklang-ora ,  I agree with your comment regarding the potential impact, and the assumption of the implementation, however, you got it the wrong way round! ;-) The change I am proposing restores previous behaviour to pre-JDK 22.  It is JDK 22 that has changed this. This is exactly why I am proposing the change

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1889016400

From vklang at openjdk.org  Fri Jan 12 12:25:18 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 12 Jan 2024 12:25:18 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <M2mFM05i_NG-UInXDzSeaw4AusHi4v6FU13PueZ9nrg=.76dd3a7e-929b-47eb-9d8d-226e2ec654cb@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <uPdu0uvZDLZUC7UHEY430KE43lMKi3IOwIKQ4Dvj2I0=.c441b990-40d3-411f-a409-326c450b1cca@github.com>
 <WWjdSTkIWyyoADLe5XRCJGYy7Xji1Yb_2KHSutUpsyk=.d857d0ce-52fe-4be2-99bd-0d7b67374643@github.com>
 <36PgGi1eMNgF3raAg-KzhJK0pjyQ7faGETzGyYiHhkg=.3ca8729f-5c25-4f77-9680-d9dd12fba849@github.com>
 <M2mFM05i_NG-UInXDzSeaw4AusHi4v6FU13PueZ9nrg=.76dd3a7e-929b-47eb-9d8d-226e2ec654cb@github.com>
Message-ID: <fZk677Q8tccLNb6Oz-W9KLCmujx9OiZ-Si4kNQvXC4I=.d09a0273-e8ae-476f-b871-6339d7144570@github.com>

On Fri, 12 Jan 2024 12:10:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>>> this PR is against mainline, but the issue's Fix Version/s is 22.
>> 
>> I updated the fix version in JIRA, and followed the process as outlined in https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html
>
>> @ChrisHegarty My 2??this change could impact existing classes which have extended LTQ and knowingly, or unknowingly, presume that add and put delegate to offer, which would (silently) break those classes when running on a newer JDK (presuming this change gets merged).
>> 
>> I think the change is in principle correct, with that said, I want to make sure that the change is worth the potential compatibility risk (if any).
> 
> Hi @viktorklang-ora ,  I agree with your comment regarding the potential impact, and the assumption of the implementation, however, you got it the wrong way round! ;-) The change I am proposing restores previous behaviour to pre-JDK 22.  It is JDK 22 that has changed this. This is exactly why I am proposing the change

@ChrisHegarty ? Well then I agree

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1889041351

From alanb at openjdk.org  Fri Jan 12 12:35:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jan 2024 12:35:18 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <EK0cgYdMcPk_7CkFi3inowJMertC00C3DpMq7zbxYXY=.7babb45d-57cc-4c6b-8ff6-32d85d1f2f07@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
 <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>
 <gF74tvhZgt8K8Sw58SRFn-dDrSRS7GNgR94rFp22BXw=.1af1403a-fb1c-4c79-a3b9-af73260a0306@github.com>
 <sW_mS9d2bWM8tjdwaq-DwbZBeEuAMDSF-LNG3RpjWvc=.8f8b7333-3310-4a4d-9e32-31bb50f97e8b@github.com>
 <EK0cgYdMcPk_7CkFi3inowJMertC00C3DpMq7zbxYXY=.7babb45d-57cc-4c6b-8ff6-32d85d1f2f07@github.com>
Message-ID: <G_ylZBsCetl_u6p900sJBRtKVS330wJTE5N1bpnrQSw=.60094cb7-7951-48e5-abe8-fe930b2fb244@github.com>

On Fri, 12 Jan 2024 11:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this one will require digging into whether the no-arg read is used in the authentication or not.

Digging into this, it seems this was looked at last year and the conclusion was this code is not used, but for some reason there wasn't a follow up JBS issue created at the time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1889064184

From dfuchs at openjdk.org  Fri Jan 12 12:35:19 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 12 Jan 2024 12:35:19 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <EK0cgYdMcPk_7CkFi3inowJMertC00C3DpMq7zbxYXY=.7babb45d-57cc-4c6b-8ff6-32d85d1f2f07@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
 <IukA2bMU2W5RZyy0btFm2w4nCnQbtsD-1rzPzXny-mA=.201d5cab-ebb1-4c9e-a5f7-766c14ae5b58@github.com>
 <gF74tvhZgt8K8Sw58SRFn-dDrSRS7GNgR94rFp22BXw=.1af1403a-fb1c-4c79-a3b9-af73260a0306@github.com>
 <sW_mS9d2bWM8tjdwaq-DwbZBeEuAMDSF-LNG3RpjWvc=.8f8b7333-3310-4a4d-9e32-31bb50f97e8b@github.com>
 <EK0cgYdMcPk_7CkFi3inowJMertC00C3DpMq7zbxYXY=.7babb45d-57cc-4c6b-8ff6-32d85d1f2f07@github.com>
Message-ID: <UPWRFc6Byf7_xAp7DmUweU7tdt1MFE-HKcKGh9VmZOA=.d382e432-2a77-4ea9-abf6-9f27d024a9cf@github.com>

On Fri, 12 Jan 2024 11:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this one will require digging into whether the no-arg read is used in the authentication or not. It might not be, in which case it's not testable with something that emulates LDAPv3. However if it is used then we should have fuzzing or other tests to exercise it. I'm not saying it should be part of this PR but finding a 15+ year issue in authentication code is concerning so will need follow-up.

AFAICT the no arg read() method is never called by the JNDI/LDAP stack. This explains why it never made any test fail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17365#issuecomment-1889065309

From chegar at openjdk.org  Fri Jan 12 12:51:20 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 12:51:20 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <QjDghUIbZOPybprwllB2lUmqNDR_89jPiZYqidR-gXM=.0709a012-aa0d-487f-afd2-a63f93bba16a@github.com>

On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Update LinkedTransferQueue add and put methods to not call overridable.

FTR - I agree that it's kinda annoying to be proposing this change and it is true that the consuming user code is making an assumption, but the impact of this is significant - leads to apparently vanishing tasks when Elasticsearch runs on JDK 22 EA. The proposed changes are extremely minimal. 

If @DougLea agrees, then I'll add a minimal test case and get the PR into a clean state.

Additionally, we absolutely need to fix this in JDK 21.0.2 - since a patch release should not change behaviour (from 21.0.1), in this way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1889097252
PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1889103827

From pminborg at openjdk.org  Fri Jan 12 13:06:39 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 12 Jan 2024 13:06:39 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v3]
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <6PFbw23ROwyaheoPmdOhrKMcDpbzZj8KwhyZi_3n-4k=.61b69d18-2539-48bf-ad6f-2d2c667eee8d@github.com>

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Move documentation of zero init to each Arena factory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17308/files
  - new: https://git.openjdk.org/jdk/pull/17308/files/04074d71..878cbcae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17308&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17308&range=01-02

  Stats: 17 lines in 1 file changed: 12 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17308.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17308/head:pull/17308

PR: https://git.openjdk.org/jdk/pull/17308

From mcimadamore at openjdk.org  Fri Jan 12 13:12:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Jan 2024 13:12:20 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v3]
In-Reply-To: <6PFbw23ROwyaheoPmdOhrKMcDpbzZj8KwhyZi_3n-4k=.61b69d18-2539-48bf-ad6f-2d2c667eee8d@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <6PFbw23ROwyaheoPmdOhrKMcDpbzZj8KwhyZi_3n-4k=.61b69d18-2539-48bf-ad6f-2d2c667eee8d@github.com>
Message-ID: <O5ZKRxOqHoMAh9GYI9D-9c3_C0BlP2LSnJdv-xlcbpU=.12591547-c226-496d-ad70-cae0e4ac96e3@github.com>

On Fri, 12 Jan 2024 13:06:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
>> 
>> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move documentation of zero init to each Arena factory

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17308#pullrequestreview-1818210976

From jvernee at openjdk.org  Fri Jan 12 13:29:20 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 12 Jan 2024 13:29:20 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v3]
In-Reply-To: <6PFbw23ROwyaheoPmdOhrKMcDpbzZj8KwhyZi_3n-4k=.61b69d18-2539-48bf-ad6f-2d2c667eee8d@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <6PFbw23ROwyaheoPmdOhrKMcDpbzZj8KwhyZi_3n-4k=.61b69d18-2539-48bf-ad6f-2d2c667eee8d@github.com>
Message-ID: <5szDCpBugeEzya180OvFWcU_AyVX7GUQt1T_njN79D8=.32197a56-beb2-42c1-b23f-48a3cffc071c@github.com>

On Fri, 12 Jan 2024 13:06:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
>> 
>> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move documentation of zero init to each Arena factory

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17308#pullrequestreview-1818263177

From pminborg at openjdk.org  Fri Jan 12 13:41:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 12 Jan 2024 13:41:48 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v4]
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <PpNDi2o0OZeOJm5SL9sNPOAimL1aJE_YljB1sIMWO5Q=.b3d03ff9-c0e8-45c5-8828-7470eb20d9c0@github.com>

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17308/files
  - new: https://git.openjdk.org/jdk/pull/17308/files/878cbcae..7723f604

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17308&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17308&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17308.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17308/head:pull/17308

PR: https://git.openjdk.org/jdk/pull/17308

From duke at openjdk.org  Fri Jan 12 13:44:28 2024
From: duke at openjdk.org (kerr)
Date: Fri, 12 Jan 2024 13:44:28 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: <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@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

Cool, I just encounter this problem, when I migrate to Virtual threads and set  `jdk.virtualThreadScheduler.maxPoolSize` to 2500.

Will this change backport to j21u, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1889239126

From pminborg at openjdk.org  Fri Jan 12 14:35:01 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 12 Jan 2024 14:35:01 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v5]
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <C6pniZ1O0VryRgkxd8VgHf1uy-R89B5GndGR-gBB3Rg=.ae95b271-2a6f-4462-aff7-6a21b8ad0612@github.com>

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Add test for zero-out

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17308/files
  - new: https://git.openjdk.org/jdk/pull/17308/files/7723f604..feb904fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17308&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17308&range=03-04

  Stats: 39 lines in 2 files changed: 37 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17308.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17308/head:pull/17308

PR: https://git.openjdk.org/jdk/pull/17308

From pminborg at openjdk.org  Fri Jan 12 14:44:27 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 12 Jan 2024 14:44:27 GMT
Subject: [jdk22] RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout, 
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario
In-Reply-To: <IT6RIYtFb00w6U4qngSXnzs-OrSw7Z1GD1ZIKVLks-4=.90ed9a8a-6ab3-4952-bbc0-d83767275f05@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
 <DNpqE12Gj0_GQGpYbjQNk1ptp2-1uSlvVdgyO19RXiY=.a5890c39-2208-4e99-ad8a-24d50516c3c9@github.com>
 <IT6RIYtFb00w6U4qngSXnzs-OrSw7Z1GD1ZIKVLks-4=.90ed9a8a-6ab3-4952-bbc0-d83767275f05@github.com>
Message-ID: <_3o82PnALwHoKzyOfn4ZX5VFzaYupm12L62J7ODh4Sg=.9787fa5a-2340-4f91-ad0e-781858f4ef1a@github.com>

On Wed, 10 Jan 2024 15:23:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/jdk/java/foreign/TestSegmentAllocators.java line 234:
>> 
>>> 232:             // WrongThreadException if this method is called from a thread {@code T},
>>> 233:             // such that {@code source.isAccessibleBy(T) == false}
>>> 234:             CompletableFuture<Arena> future = CompletableFuture.supplyAsync(Arena::ofConfined);
>> 
>> I believe TestScopedOperations should check for WTE as well?
>
> That test has two methods: `testOpAfterClose` and `testOpOutsideConfinement`, which are executed on all the test cases.

Good idea. We could do that in a separate PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk22/pull/42#discussion_r1450537639

From pminborg at openjdk.org  Fri Jan 12 14:44:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 12 Jan 2024 14:44:28 GMT
Subject: [jdk22] Integrated: 8321786:
 SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
In-Reply-To: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
References: <XPxJkaf_4yHMM-wLOnyCX7rfRAhv6nvW74oP7jWMCLI=.c7353d55-3f3f-4157-bc9e-7fee89b64f95@github.com>
Message-ID: <G2vCRRxilUKRKwWS45Vf2HTkIjMQxrdMT6MvAOU-OKk=.06c1238a-5ff8-4462-8bad-6c6ab72ec946@github.com>

On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> 8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

This pull request has now been integrated.

Changeset: 3909d74a
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/3909d74af562006ff8c117a5cef99dbbbde4c24d
Stats:     239 lines in 13 files changed: 200 ins; 21 del; 18 mod

8321786: SegmentAllocator:allocateFrom(ValueLayout, MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario

Reviewed-by: mcimadamore
Backport-of: 7edd10e5fa71dafbbad23455553b7f5ff0a75ac9

-------------

PR: https://git.openjdk.org/jdk22/pull/42

From dfuchs at openjdk.org  Fri Jan 12 14:49:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 12 Jan 2024 14:49:20 GMT
Subject: RFR: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
Message-ID: <oJv5SGuxTLXh8P14v6Xx0t00b8YNPbEcfvMNf-nRCHM=.c532cd07-00b4-4fbd-8bab-8ac87fe74054@github.com>

On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17365#pullrequestreview-1818425451

From chegar at openjdk.org  Fri Jan 12 14:52:42 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 14:52:42 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v2]
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <fDp83uGQNMnlxgTluyrG5L52WzHHtoXX9deaFiBZniw=.f2d9ca1d-7de8-4fd0-bf63-664533b590e0@github.com>

> Update LinkedTransferQueue add and put methods to not call overridable offer.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17393/files
  - new: https://git.openjdk.org/jdk/pull/17393/files/206e2652..b11804d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=00-01

  Stats: 60 lines in 1 file changed: 60 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From chegar at openjdk.org  Fri Jan 12 15:06:01 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 15:06:01 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>

> Update LinkedTransferQueue add and put methods to not call overridable offer.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  timed offer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17393/files
  - new: https://git.openjdk.org/jdk/pull/17393/files/b11804d1..1097a6bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=01-02

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From chegar at openjdk.org  Fri Jan 12 15:06:01 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 12 Jan 2024 15:06:01 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
Message-ID: <JgAMxVb1psnAC7TIhM02rCsCoKW4RdBKZB6of9m59KU=.98d8c5c3-9df5-49a7-837f-b4e4054a9c3e@github.com>

On Fri, 12 Jan 2024 15:02:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   timed offer

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 1160:

> 1158:      */
> 1159:     public boolean offer(E e, long timeout, TimeUnit unit) {
> 1160:         Objects.requireNonNull(e);

While here, it makes sense to update the timed offer variant, since it is affected in a similar way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17393#discussion_r1450573006

From pminborg at openjdk.org  Fri Jan 12 15:26:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 12 Jan 2024 15:26:09 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign
Message-ID: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>

This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build.

-------------

Commit messages:
 - Exclude snipet files

Changes: https://git.openjdk.org/jdk/pull/17403/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17403&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323621
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17403/head:pull/17403

PR: https://git.openjdk.org/jdk/pull/17403

From duke at openjdk.org  Fri Jan 12 15:35:20 2024
From: duke at openjdk.org (sendaoYan)
Date: Fri, 12 Jan 2024 15:35:20 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
References: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
Message-ID: <170e6zHFDiV7S-wjywSB0jTAIwb-OnyTAgtWWwQft4I=.cfb79650-9127-45d3-ab22-89cacf9dec1b@github.com>

On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan <duke at openjdk.org> wrote:

> Reviewed-by: Yi Yang

The test case before this PR has a maximum heap of 64MB and applies for 8M of memory each time in the for loop. When applying for memory for the sixth time, it was killed by the docker container because of OOM, jdk.internal.platform.Metrics.systemMetrics().getMemoryFailCount( ) interface has no chance to return 1, and the Java process returns exit code 137. The maximum heap is also 64M, The PR is changed to 1KB each time to ensure that the getMemoryFailCount() interface has a chance to return 1 and the test case has a chance to exit the for loop of memory allocation.

## test result before this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/4554dd00-6da5-4529-907a-45e2df5c902b)


## test result after this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/32ea4fc8-aa04-425e-8481-a920265d2b1f)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17386#issuecomment-1889517014

From redestad at openjdk.org  Fri Jan 12 16:17:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Jan 2024 16:17:22 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: <GjN6Vnfpe88v0rNP4WH9EeO-8ROfgH93OL3K0OT1KRc=.978dc8d1-f9a1-47ba-9d6d-d55079694376@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 had to merge with master to get jlink to work, perhaps some local issue since Classfile API has been moving around. 

While the improvement to `--compress 1` are impressive, this compression mode is effectively deprecated. I'm not sure your improvements to it here will be enough to reverse that decision (it's still a bit behind on all measures, no?). Perhaps it would be better to split out those changes and move forward with and focus this on the zip decompressor enhancements?

-------------

PR Review: https://git.openjdk.org/jdk/pull/16556#pullrequestreview-1818606132

From duke at openjdk.org  Fri Jan 12 17:02:25 2024
From: duke at openjdk.org (Glavo)
Date: Fri, 12 Jan 2024 17:02:25 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <D5jQLveRWW7ftPVTkLTeMa9bvbwx8dHWmuQvZ-0FkCE=.cd26f683-8981-43d3-9e76-3d27693528c1@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <Sj839pWrpFu6T-goUr3QXvrtHxKETEmH9-2jZ1kYKZc=.b75e06cc-5655-416a-9413-9f545d900e4a@github.com>
 <D5jQLveRWW7ftPVTkLTeMa9bvbwx8dHWmuQvZ-0FkCE=.cd26f683-8981-43d3-9e76-3d27693528c1@github.com>
Message-ID: <UuFypQq9jSIg5vbB0xKb_4fD8IL-G1ILjQlIdFFPY-g=.70accd11-e0f5-4245-bdb8-7dce6cbb2fd8@github.com>

On Fri, 8 Dec 2023 22:38:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Does anyone want to take a look at this PR?
>
>> 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.

@cl4es 

> While the improvement to --compress 1 are impressive, this compression mode is effectively deprecated.

I noticed the deprecation warning before creating this PR, so I did some research.

This warning was introduced here: https://github.com/openjdk/jdk/pull/11617. In the discussion of that PR I learned that the option `--compress 1` was deprecated because it was not compression but string sharing. The string sharing plugin is not actually deprecated, it's just that it may be renamed in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1889649725

From sgehwolf at openjdk.org  Fri Jan 12 17:15:26 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 12 Jan 2024 17:15:26 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
Message-ID: <QZ94TIavipCvrdj9KK8D549F8MCpsg4tY5p3Rmhmrs8=.39b18198-e69a-466b-9890-57437fe41491@github.com>

On Thu, 28 Dec 2023 15:19:23 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> 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

It looks like this patch needs a bit more discussion. Generally, it would be good to have the functionality, but I'm unsure about the proposed implementation.

Walking the directory hierarchy (**and** interface files) on every call of `physical_memory()` (or `active_processor_count()` for CPU) seems concerning. Since it seems unlikely for cgroup interface file paths changing during runtime, walking the hierarchy for every look-up seems overkill. Note that the prime users of this feature are in-container use, where most runtimes have the limit settings at the leaf. A few more comments below:

- After this patch, AFAIUI for a cgroup path like `/foo/bar/baz/memory.max` the following files are being looked at for the memory limit (for example for the interface file `memory.max`):
  ```
   /foo/bar/baz/memory.max
   /foo/bar/memory.max
   /foo/memory.max
  ```
  This used to be just one file at the leaf, `/foo/bar/baz/memory.max` (prior this patch). So this change has an effect on file IO. `N` files per metric to look at where it used to be one file (i.e. constant). Note that switches like `UseDynamicNumberOfCompilerThreads` make this particularly worrying.  I wonder if it would be sufficient to "lock" into the cgroup path where the lowest  limits are set in the hierarchy and only use the interface files at that path of a specific controller. This would mean adjusting `CgroupsV2Subsystem` similar to `CgroupsV1Subsystem` to have unique controller paths (i.e. `cpu` and `memory` controller paths could potentially be different). But the code would already be mostly there for this. The idea would be to do the initial walk of the tree at JVM startup, and from then on, only look at the path with a limit set (if any) for subsequent calls. That is `controller->subsystem_path()` would return the correct path at runtime when initialization is done. T
 houghts?
- There seems to be an inconsistency between cgroups v1 (no recursive look-up) and cgroups v2  (recursive look-up). Why? I think we should employ the same semantics to both  versions (and drop the hierarchical work-around - [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338) - for cg v1).
- There also seems to be an inconsistency between metrics being iterated. `memory.max` and `memory.swap.max`  and `memory.swap.current` are being iterated, others, like CPU quotas (`cpu.max` or
  `cpu.weight`) not. Why? Both limits could potentially be one path up the hierarchy, meaning that cpu limits imposed that way wouldn't be detected.
- What testing have you done on this? Did this run through cgroups v1 and cgroups v2  testing? I see failures in `jdk/internal/platform/cgroup` tests (compilation fails).

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 287:

> 285:   _paths_size = 0;
> 286:   for (const char *cs = _cgroup_path; (cs = strchr(cs, '/')); ++cs)
> 287:     ++_paths_size;

What happens if we end up having multiple slashes? Like `/foo//bar/baz`? This logic would be a good candidate for having a gtest.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 30:

> 28:  * @requires vm.flagless
> 29:  * @library /testlibrary /test/lib
> 30:  * @run driver jdk.test.lib.helpers.ClassFileInstaller

This ClassFileInstaller seems not needed.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 94:

> 92:         cgdelete.add("-g");
> 93:         cgdelete.add(CONTROLLERS_PATH_OUTER);
> 94:         pSystem(cgdelete);

This deletes a control group which might not have been created. On my system that test fails due to that.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 97:

> 95: 
> 96:         List<String> cgcreate = new ArrayList<>();
> 97:         cgcreate.add("cgcreate");

This test relies on `cgcreate` being present on the test system. I wonder if we could create a similar test with using `systemd-slices`  only. Either way, we need to have a corresponding check that this test dependency is there a. la. `@requires docker`.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 112:

> 110:         if (!matcher.find()) {
> 111:             System.err.println(mountInfo);
> 112:             throw new SkippedException("cgroup2 filesystem mount point not found");

Why is this check there? It should be the same for hierachical cgroup v1 systems (most of them), no? My testing of the `cgcreate` flow suggests it's the same on `v1`. It's just not as visible since there are per controller paths in `/proc/self/cgroup` on `v1` and we have the hierarchical memory limit work-around employed on v1.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17198#pullrequestreview-1816085160
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1449164637
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1450686310
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1450465850
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1450673701
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1450540176

From erikj at openjdk.org  Fri Jan 12 17:34:20 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Jan 2024 17:34:20 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign
In-Reply-To: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
Message-ID: <MtsPgVmBNjn9nfy9YkEGsnCs8PYVRuVlxZmfaa7YirY=.b4929117-6436-444a-9805-756f1ecf6648@github.com>

On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build.

make/modules/java.base/Java.gmk line 41:

> 39:     java/lang/classfile/snippet-files \
> 40:     java/lang/classfile/components/snippet-files \
> 41:     jdk/lang/foreign/snippet-files

I can't find this directory in the source tree, but there is a `src/java.base/share/classes/java/lang/foreign/snippet-files`. Is that what you want to exclude?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17403#discussion_r1450739475

From alanb at openjdk.org  Fri Jan 12 17:40:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jan 2024 17:40:21 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier [v3]
In-Reply-To: <0Yn_cuirspDc9gpJsMeFe3bDKtIwvsUCwdW9snv91jI=.37c33f82-9d2d-4baa-91d5-54f919765068@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
 <0Yn_cuirspDc9gpJsMeFe3bDKtIwvsUCwdW9snv91jI=.37c33f82-9d2d-4baa-91d5-54f919765068@github.com>
Message-ID: <1jjgwBMirNhOz-dRWS7VsDen_0Em_UqpJrDwBnl_rqI=.d8428fd3-518f-42cb-b999-a6c0c85d6698@github.com>

On Fri, 12 Jan 2024 07:38:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine wording per review feedback.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17338#pullrequestreview-1818743339

From lmesnik at openjdk.org  Fri Jan 12 17:45:24 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 Jan 2024 17:45:24 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v3]
In-Reply-To: <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
 <iJzkuxb69kFzlh_ArTp7PVQZkwPxBz36LKvRAHjYMb0=.4475ffa2-65f2-4156-9576-f357a25b3253@github.com>
Message-ID: <YEz2mlqCwutByMB5yQhK4b4sw30UJ-fjNjjQYXL10AA=.0107a007-d552-4cff-87cb-95190bda15d1@github.com>

On Fri, 5 Jan 2024 09:07:57 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 with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8320699_OutputAnalyzer_progress_logging
>  - Update OutputBuffer.java copyright years
>  - 8320699: Add parameter to skip progress logging of OutputAnalyzer

I think that commit is going to have date in 2024. So any check is going to compare this date and copyright year. It shouldn't cause fail i CI and files are going to be updated later with  verification scripts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1889709770

From darcy at openjdk.org  Fri Jan 12 18:11:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 18:11:31 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier [v4]
In-Reply-To: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
Message-ID: <twCgN0YdW9SZ9OmoPX810TH7VpYTw_Frcxp8d9jbMOU=.82545ed7-e7e7-4d73-ac2c-e568aca4a694@github.com>

> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Reflow paragraph.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17338/files
  - new: https://git.openjdk.org/jdk/pull/17338/files/cc67f321..dabd8edd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17338&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17338&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17338/head:pull/17338

PR: https://git.openjdk.org/jdk/pull/17338

From mchung at openjdk.org  Fri Jan 12 18:20:23 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 12 Jan 2024 18:20:23 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: <kAwQurI8AffFe53UgaobbqDdolz_zgumT3avbynOdnc=.b88877fb-685c-48d7-8739-c3c2c682ad72@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).

The plan [1] is to remove the old compression values `0`, `1`, `2` in the future and only support the zip compression `--compress zip-[0-9]`, i.e. the string sharing plugin will be removed as there isn't any known customer usage of this plugin.   If you are aware of any customer using it, we can reevaluate.

[1] https://bugs.openjdk.org/browse/JDK-8301124?focusedId=14562770&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14562770

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1889753527

From jlu at openjdk.org  Fri Jan 12 18:27:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 18:27:55 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v3]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <G2RApo4uByIHt5YIch5GttpbuanxN8MDwpR-I_SGSmo=.4c88f861-095d-4096-8c48-8e33d5fbc4d2@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - swap placement of decimal pattern and compact patterns. Expand on tests
 - add unit tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/1dfc949d..3157ec8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=01-02

  Stats: 359 lines in 7 files changed: 357 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

PR: https://git.openjdk.org/jdk/pull/17355

From jlu at openjdk.org  Fri Jan 12 18:27:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 18:27:55 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v2]
In-Reply-To: <DfkwfopSoREFkqMQ6N8dookEIBrMpIW7hnXc9rFgBXA=.b32455fe-20b2-4579-9136-f60ae82f6ee3@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>
 <DfkwfopSoREFkqMQ6N8dookEIBrMpIW7hnXc9rFgBXA=.b32455fe-20b2-4579-9136-f60ae82f6ee3@github.com>
Message-ID: <ZfeuSUwnrvTDWDTpIUR9xLug1zqg8TA5y7_7FxBTK1M=.5c4f5a90-1893-47c9-9ddc-ce87811884cb@github.com>

On Thu, 11 Jan 2024 19:42:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think test cases for these new overridden `toString()` methods would be helpful.

Added test cases for the new methods. Additionally, in the most recent commit, I swapped the placement of `compact patterns` with `decimal pattern`. As `compact patterns` is generally much longer, I felt it helped readability if `decimal pattern` came first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17355#issuecomment-1889761787

From jlu at openjdk.org  Fri Jan 12 18:31:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 18:31:48 GMT
Subject: [jdk22] RFR: 8322235: Split up and improve LocaleProvidersRun
Message-ID: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>

Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

-------------

Commit messages:
 - Backport 4ea7b36447ea96d62b1ca164c34e2b2b74a16579

Changes: https://git.openjdk.org/jdk22/pull/68/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=68&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322235
  Stats: 569 lines in 8 files changed: 425 ins; 85 del; 59 mod
  Patch: https://git.openjdk.org/jdk22/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/68/head:pull/68

PR: https://git.openjdk.org/jdk22/pull/68

From duke at openjdk.org  Fri Jan 12 18:36:22 2024
From: duke at openjdk.org (Glavo)
Date: Fri, 12 Jan 2024 18:36:22 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <kAwQurI8AffFe53UgaobbqDdolz_zgumT3avbynOdnc=.b88877fb-685c-48d7-8739-c3c2c682ad72@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <kAwQurI8AffFe53UgaobbqDdolz_zgumT3avbynOdnc=.b88877fb-685c-48d7-8739-c3c2c682ad72@github.com>
Message-ID: <4_TzekuqaKz6YOSVd4xCvRgUydk45XX_lQn8Dviehfc=.6d6f41c0-78c9-454e-b2ef-665275f5aede@github.com>

On Fri, 12 Jan 2024 18:17:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The plan [1] is to remove the old compression values `0`, `1`, `2` in the future and only support the zip compression `--compress zip-[0-9]`, i.e. the string sharing plugin will be removed as there isn't any known customer usage of this plugin. If you are aware of any customer using it, we can reevaluate.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8301124?focusedId=14562770&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14562770

I expected that few people use this option, because compared to zip, it is not superior in file size or decompression speed. However, I did some experiments in the [JApp](https://github.com/Glavo/japp) project and found that the file size using a mixture of string sharing + zstd compression was significantly smaller than using only zstd, so I thought it might be meaningful to study it further.

Anyway, these are things for the future and I want this PR to stay simple, so I'll just drop these modifications.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1889773413

From duke at openjdk.org  Fri Jan 12 18:51:31 2024
From: duke at openjdk.org (Glavo)
Date: Fri, 12 Jan 2024 18:51:31 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: <Cj4RZxm-8dS4sO9w9niCLjSHnh_QPRiCJBVE5mmhgVI=.8ac90f9c-1137-4789-8285-696fbd351d82@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 created a new PR: #17405

I want to leave my changes to the string sharing plugin here so I can pick them up in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1889790269

From duke at openjdk.org  Fri Jan 12 18:51:32 2024
From: duke at openjdk.org (Glavo)
Date: Fri, 12 Jan 2024 18:51:32 GMT
Subject: Withdrawn: 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: <RVbh1Uz19vm4CNSrd0lT9tQo3Vi31BE-mkhYAzvk7Xg=.63902e84-e13e-4570-94b9-b66596fe348d@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).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16556

From naoto at openjdk.org  Fri Jan 12 18:52:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Jan 2024 18:52:24 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v3]
In-Reply-To: <G2RApo4uByIHt5YIch5GttpbuanxN8MDwpR-I_SGSmo=.4c88f861-095d-4096-8c48-8e33d5fbc4d2@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <G2RApo4uByIHt5YIch5GttpbuanxN8MDwpR-I_SGSmo=.4c88f861-095d-4096-8c48-8e33d5fbc4d2@github.com>
Message-ID: <QCuMjRWFevrfhEQaDdBA_xnZLH3WHpc7AZG4nL0ILJE=.1211f409-2c77-45b7-92c5-a354e1b721a4@github.com>

On Fri, 12 Jan 2024 18:27:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - swap placement of decimal pattern and compact patterns. Expand on tests
>  - add unit tests

Added tests look good.

src/java.base/share/classes/java/text/MessageFormat.java line 1195:

> 1193:             """
> 1194:             MessageFormat [locale: "%s", pattern: "%s"]
> 1195:             """.formatted(locale == null ? "None" : locale.getDisplayName(), toPattern());

I think printing `null` for `locale == null` is better here, as `None` is sort of ambiguous. Applies to SDF (and related tests) as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17355#pullrequestreview-1818845217
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1450811275

From duke at openjdk.org  Fri Jan 12 18:53:28 2024
From: duke at openjdk.org (Glavo)
Date: Fri, 12 Jan 2024 18:53:28 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
Message-ID: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>

I generated runtime images using `jlink --compress 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:


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 70% while decompression speed is significantly improved.

-------------

Commit messages:
 - Update ZipDecompressor

Changes: https://git.openjdk.org/jdk/pull/17405/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17405&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321620
  Stats: 21 lines in 1 file changed: 10 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17405/head:pull/17405

PR: https://git.openjdk.org/jdk/pull/17405

From naoto at openjdk.org  Fri Jan 12 18:56:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Jan 2024 18:56:33 GMT
Subject: [jdk22] RFR: 8322235: Split up and improve LocaleProvidersRun
In-Reply-To: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
References: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
Message-ID: <ClMc3-aP9mHwD0BNSBor31_kklT9wB2E13Rtqc8-0TQ=.18ffa200-748e-4385-8649-60081e5650ae@github.com>

On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/68#pullrequestreview-1818853193

From jlu at openjdk.org  Fri Jan 12 19:07:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 19:07:46 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v4]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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 eight additional commits since the last revision:

 - replace 'None' with 'null' for applicable classes
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - swap placement of decimal pattern and compact patterns. Expand on tests
 - add unit tests
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - account for null locale for SDF through deserialization
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/3157ec8e..fa2345a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=02-03

  Stats: 5909 lines in 110 files changed: 3521 ins; 2087 del; 301 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

PR: https://git.openjdk.org/jdk/pull/17355

From rriggs at openjdk.org  Fri Jan 12 19:17:23 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Jan 2024 19:17:23 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v14]
In-Reply-To: <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
Message-ID: <Oe2zMW-fiQ4i3b1fEJN3DOgNWMxgU7UgqgbDsKmvQic=.be089074-d7a1-4152-97b8-cb10d30ae26b@github.com>

On Wed, 10 Jan 2024 18:56:45 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:
> 
>   Small space optimization.

Thanks for the updates.  LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17129#pullrequestreview-1818884173

From iris at openjdk.org  Fri Jan 12 19:32:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 12 Jan 2024 19:32:23 GMT
Subject: [jdk22] RFR: 8322235: Split up and improve LocaleProvidersRun
In-Reply-To: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
References: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
Message-ID: <tcHnZt-jLsJwE-xGM6LGI2PdKzxX-2v4b80LN8-rkc0=.4417983b-7a78-4203-ac2c-45f38be4ddf2@github.com>

On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

Confirmed identical to changes in main-line.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/68#pullrequestreview-1818908921

From naoto at openjdk.org  Fri Jan 12 19:38:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Jan 2024 19:38:23 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v4]
In-Reply-To: <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
Message-ID: <aGyoRikBNZ1XikBUG65Bf9HFJlr94_x1nlJzeY8aMPY=.b9f60cde-52e8-49b7-8c85-9c52e7f15537@github.com>

On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> 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 eight additional commits since the last revision:
> 
>  - replace 'None' with 'null' for applicable classes
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - swap placement of decimal pattern and compact patterns. Expand on tests
>  - add unit tests
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - account for null locale for SDF through deserialization
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - init

LGTM. The `locale` object could be passed to `formatted()` argument instead of the hard-coded `"null"`, but that is ok

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17355#pullrequestreview-1818919978

From darcy at openjdk.org  Fri Jan 12 19:43:28 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Jan 2024 19:43:28 GMT
Subject: Integrated: JDK-8322979: Add informative discussion to Modifier
In-Reply-To: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
Message-ID: <e2yor5Pm1ttzR-2KmIjZFzvlLyHIttRMdc3_fsXtYXs=.33d4254b-9169-40c6-aa69-a8c30f7293f2@github.com>

On Wed, 10 Jan 2024 06:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a few apiNote concerning source-level modifiers that are not represented in java.lang.reflect.Modifier.

This pull request has now been integrated.

Changeset: 9e9c05f0
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e9c05f0eee7c3ecc750c212e6fe5edddb8c6ed8
Stats:     27 lines in 1 file changed: 26 ins; 0 del; 1 mod

8322979: Add informative discussion to Modifier

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17338

From mchung at openjdk.org  Fri Jan 12 19:54:19 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 12 Jan 2024 19:54:19 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <1klyfbvdNS5Mx_uykPnebSjDCGhT2j9G8PW-cry-WOg=.5bb11323-c9c6-4f7c-abf9-79f6ada104cb@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

Looks good to me.  Should wait for @cl4es review as he looked at the previous version.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17405#pullrequestreview-1818948375

From rriggs at openjdk.org  Fri Jan 12 21:36:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Jan 2024 21:36:24 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v4]
In-Reply-To: <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
Message-ID: <ROYcHd4rqA0XB__-nHTZJ2YXNwxybW1fcREDnT7L4C4=.4d810fff-6c92-4045-8f0d-a6ba73db040c@github.com>

On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> 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 eight additional commits since the last revision:
> 
>  - replace 'None' with 'null' for applicable classes
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - swap placement of decimal pattern and compact patterns. Expand on tests
>  - add unit tests
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - account for null locale for SDF through deserialization
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - init

src/java.base/share/classes/java/text/MessageFormat.java line 1195:

> 1193:             """
> 1194:             MessageFormat [locale: "%s", pattern: "%s"]
> 1195:             """.formatted(locale == null ? "null" : locale.getDisplayName(), toPattern());

It would be more accurate if when locale ==null that null was not quoted in the string.
Seeing "null" would imply that the displayName of the locale was "null", when it was `null`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1450941057

From jlu at openjdk.org  Fri Jan 12 22:41:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 22:41:46 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v5]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <RitaZ1Ej-sjgHl4bgPsJLJ5hD-z3ljeWQ0n8vFrquQQ=.2f860079-c0d4-41eb-894a-a78f6f687134@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  remove quotes around locale when equal to null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/fa2345a2..70e0a175

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=03-04

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

PR: https://git.openjdk.org/jdk/pull/17355

From serb at openjdk.org  Fri Jan 12 23:55:28 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Jan 2024 23:55:28 GMT
Subject: Integrated: 8323562: SaslInputStream.read() may return wrong value
In-Reply-To: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
References: <rFOI23HjPXPT-90NdsEV_b1gLBIhIImQbvxkNT4Xckc=.be0bbed6-8559-47fa-814c-d36ab7083247@github.com>
Message-ID: <47Mv6IUwH06KF8I7we_UsnM9EHJZRjqryEPwKIQ2TCk=.b77ab76b-36b7-4b0a-aeb4-fe7d114d318e@github.com>

On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SaslInputStream.read() should return a value in the range from 0 to 255 per the spec of InputStream.read() but it returns the signed byte from the inBuf as is.

This pull request has now been integrated.

Changeset: 5cf7947c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cf7947ccd1fc56e8944c28145a9c8e71f5e1a03
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8323562: SaslInputStream.read() may return wrong value

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: shade, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/17365

From gli at openjdk.org  Sat Jan 13 11:01:35 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 13 Jan 2024 11:01:35 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
 <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@github.com>
Message-ID: <PziUsRNvMyPqV4eS6lFEEdG80nX4dpTKtqv4zI27ZpM=.77e6e03d-f629-4baf-b3d5-a5ef84afe31b@github.com>

On Fri, 12 Jan 2024 13:41:39 GMT, kerr <duke at openjdk.org> wrote:

>> 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
>
> Cool, I just encounter this problem, when I migrate to Virtual threads and set  `jdk.virtualThreadScheduler.maxPoolSize` to 2500.
> 
> Will this change backport to j21u, thanks.

@He-Pin I tried to backport this patch for you just now [1]. But it can't be automatically backported because JDK-8288899 [2][3] also revised the file `src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java`. Do you want to backport these two patches? Or only this one?

[1] https://github.com/openjdk/jdk/commit/cc25d8b12bbab9dde9ade7762927dcb8d27e23c5#commitcomment-136982984
[2] https://bugs.openjdk.org/browse/JDK-8288899
[3] https://git.openjdk.org/jdk/pull/14301

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1890417612

From duke at openjdk.org  Sat Jan 13 16:35:18 2024
From: duke at openjdk.org (Glavo)
Date: Sat, 13 Jan 2024 16:35:18 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <0kuVWkPoe7FHpdmioR0e52opXIO4384jo9Q8ekrBroA=.d1e1cc78-e8aa-425e-a3a7-2cb2cdcd7fad@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

I ran tier1~tier2 tests and there were no new failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1890586437

From archie.cobbs at gmail.com  Sat Jan 13 18:45:50 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sat, 13 Jan 2024 12:45:50 -0600
Subject: Is MessageFormat.toPattern() supposed to be reversible?
Message-ID: <CANSoFxsfnJY-vsaceAOL3dK_c9=ShDaaKz_RmdnMyLwmxsdVsA@mail.gmail.com>

Clarification question regarding MessageFormat.toPattern() before I file a
bug...

Is it supposed to be the case that given a MessageFormat object fmt, new
MessageFormat(fmt.toPattern()) is equivalent to the original fmt object?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240113/f1480e99/attachment.htm>

From duke at openjdk.org  Sat Jan 13 19:48:28 2024
From: duke at openjdk.org (kerr)
Date: Sat, 13 Jan 2024 19:48:28 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
 <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@github.com>
Message-ID: <ac3QapbHWEyKS-n5raQ8m6oZ6Zi5bZV_4I0ENC5j-PI=.1db57e20-5e03-41ec-ad8a-4a5c81a845f5@github.com>

On Fri, 12 Jan 2024 13:41:39 GMT, kerr <duke at openjdk.org> wrote:

>> 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
>
> Cool, I just encounter this problem, when I migrate to Virtual threads and set  `jdk.virtualThreadScheduler.maxPoolSize` to 2500.
> 
> Will this change backport to j21u, thanks.

> @He-Pin I tried to backport this patch for you just now [1]. But it can't be automatically backported because JDK-8288899 [2][3] also revised the file `src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java`. Do you want to backport these two patches? Or only this one?
> 
> [1] https://github.com/openjdk/jdk/commit/cc25d8b12bbab9dde9ade7762927dcb8d27e23c5#commitcomment-136982984
> [2] https://bugs.openjdk.org/browse/JDK-8288899
> [3] https://git.openjdk.org/jdk/pull/14301

I think the related issue should be backported too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1890750696

From liach at openjdk.org  Sun Jan 14 04:10:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 14 Jan 2024 04:10:21 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign
In-Reply-To: <MtsPgVmBNjn9nfy9YkEGsnCs8PYVRuVlxZmfaa7YirY=.b4929117-6436-444a-9805-756f1ecf6648@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
 <MtsPgVmBNjn9nfy9YkEGsnCs8PYVRuVlxZmfaa7YirY=.b4929117-6436-444a-9805-756f1ecf6648@github.com>
Message-ID: <KAFMo9ebt4Lh5sRAqV5rdUbbqhWPYDJJQ_R9UjMqbe8=.157b9c1a-58a9-4412-9950-119f5a73b3ee@github.com>

On Fri, 12 Jan 2024 17:31:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build.
>
> make/modules/java.base/Java.gmk line 41:
> 
>> 39:     java/lang/classfile/snippet-files \
>> 40:     java/lang/classfile/components/snippet-files \
>> 41:     jdk/lang/foreign/snippet-files
> 
> I can't find this directory in the source tree, but there is a `src/java.base/share/classes/java/lang/foreign/snippet-files`. Is that what you want to exclude?

If possible, we should simply exclude all files in directories that have `-` (minus sign) in their name; this is the intentional design to prevent javac from compiling those classes as package names cannot include `-`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17403#discussion_r1451650904

From acobbs at openjdk.org  Sun Jan 14 15:36:37 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 14 Jan 2024 15:36:37 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern
Message-ID: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>

Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.

The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.

In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.

The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.

So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.

An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.

However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.

As a result, invoking `f.format(new Object{} { 0, 5 })` will return `"option A: 5"` using the original `MessageFormat` but `"option A: 5}"` from a new one created with the string from `toPattern()`.

This patch fixes this problem by adding quotes around "extra" closing braces in the subformat pattern strings.

-------------

Commit messages:
 - Quote runs of extra unquoted closing braces in subformat patterns.

Changes: https://git.openjdk.org/jdk/pull/17416/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323699
  Stats: 103 lines in 2 files changed: 100 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From liach at openjdk.org  Sun Jan 14 16:33:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 14 Jan 2024 16:33:36 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
Message-ID: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>

API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html

Additional questions:
1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

-------------

Commit messages:
 - redundant line
 - Fix a test in langtools, copyright year
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Implementation cleanup, test update
 - Merge branch 'master' into fix/typearg-model
 - Formatting
 - Nuke signatureString and fix test fialure from bad cast
 - Adjust the type arg model to better represent the embodied type

Changes: https://git.openjdk.org/jdk/pull/16517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323707
  Stats: 130 lines in 6 files changed: 46 ins; 32 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/16517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517

PR: https://git.openjdk.org/jdk/pull/16517

From duke at openjdk.org  Sun Jan 14 16:33:37 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 14 Jan 2024 16:33:37 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
In-Reply-To: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
Message-ID: <_yj_29oiqHBjdbwOPy8MC4uPQBScN5FpsG-Ah_QTW-g=.db327b2e-9f22-4804-973f-3e631ce8e782@github.com>

On Mon, 6 Nov 2023 07:30:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

src/java.base/share/classes/jdk/internal/classfile/Signature.java line 252:

> 250:         public static TypeArg.Bounded bounded(Bounded.WildcardIndicator wildcard, RefTypeSig boundType) {
> 251:             return new SignaturesImpl.TypeArgImpl(wildcard, boundType);
> 252:         }

Suggestion:

        public static TypeArg.Bounded bounded(Bounded.WildcardIndicator wildcard, RefTypeSig boundType) {
            requireNonNull(wildcard);
            requireNonNull(boundType);
            return new SignaturesImpl.TypeArgImpl(wildcard, boundType);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1405426776

From redestad at openjdk.org  Sun Jan 14 17:19:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 14 Jan 2024 17:19:20 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <cC9ch-S04lWwCA9MPUMm-nHZnSYlhayHjznJCNZJZ68=.64dbad58-3148-4718-b54d-5005dec7db07@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

Looks good to me!

Pre-existing issue here is that it seems we don't handle compressed resources that can't fit in a single `byte[]`, yet we take the overhead of storing uncompressed/compressed size as longs (4+4 byte overhead per entry). I guess we should either add code to handle huge entries or optimize the compressed header to store int sizes.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17405#pullrequestreview-1820272923

From archie.cobbs at gmail.com  Sun Jan 14 19:02:41 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 14 Jan 2024 13:02:41 -0600
Subject: Is MessageFormat.toPattern() supposed to be reversible?
In-Reply-To: <CANSoFxsfnJY-vsaceAOL3dK_c9=ShDaaKz_RmdnMyLwmxsdVsA@mail.gmail.com>
References: <CANSoFxsfnJY-vsaceAOL3dK_c9=ShDaaKz_RmdnMyLwmxsdVsA@mail.gmail.com>
Message-ID: <CANSoFxv-jDNSpRiU2zLnSbsj92eDk=QReGL8fxkWb6T723DMLg@mail.gmail.com>

Nevermind, I believe now it is and have filed JDK-8323699. Thanks.

On Sat, Jan 13, 2024 at 12:45?PM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

> Clarification question regarding MessageFormat.toPattern() before I file a
> bug...
>
> Is it supposed to be the case that given a MessageFormat object fmt, new
> MessageFormat(fmt.toPattern()) is equivalent to the original fmt object?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240114/d89c7db4/attachment.htm>

From duke at openjdk.org  Mon Jan 15 01:47:22 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 15 Jan 2024 01:47:22 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <cC9ch-S04lWwCA9MPUMm-nHZnSYlhayHjznJCNZJZ68=.64dbad58-3148-4718-b54d-5005dec7db07@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
 <cC9ch-S04lWwCA9MPUMm-nHZnSYlhayHjznJCNZJZ68=.64dbad58-3148-4718-b54d-5005dec7db07@github.com>
Message-ID: <mlCYaFHcK6jWtGOZVC2Soopd4fEoblBkrNaUZv8AgHI=.5f952817-2baa-468d-9140-a9f33dd1d6fc@github.com>

On Sun, 14 Jan 2024 17:16:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Pre-existing issue here is that it seems we don't handle compressed resources that can't fit in a single byte[], yet we take the overhead of storing uncompressed/compressed size as longs (4+4 byte overhead per entry). I guess we should either add code to handle huge entries or optimize the compressed header to store int sizes.

This limitation is so deep-rooted that it is difficult to resolve it for the time being. But I don't think this is causing any problems for the time being. There is no need to put an overly large resource in a jimage file, it will be better placed elsewhere.

But even so, I think it's appropriate to store the size as 64 bits, which will make it easier to lift this restriction in the future. If you want the size of the metadata, I think it is more appropriate to compress the metadata. I tried using zstd to compress the metadata in [JApp](https://github.com/Glavo/japp) and got good results. We might be able to do this in jimage as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1891175153

From dholmes at openjdk.org  Mon Jan 15 01:58:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 01:58:22 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
Message-ID: <iiXBJ-r0vq2JJCPTB2iIV5oTi4JNmNDkO1V5CFPd_p8=.ff7b9633-f4f4-492a-8ddc-56033ba2e997@github.com>

On Fri, 12 Jan 2024 15:06:01 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   timed offer

With my CSR hat on, JDK-8301341 should never have made the changes it did without going through a CSR request. We have been bitten by this kind of problem many times. Unless a public method is specified to utilise another public method, we should never implement one public method in terms of another (non-final one) due to the overriding problem. Backporting such a change to 21u is then potentially very damaging.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1891184409

From duke at openjdk.org  Mon Jan 15 02:33:21 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 15 Jan 2024 02:33:21 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
In-Reply-To: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
Message-ID: <ucgottWGuHTVA_NdHh2ihwUieoQBMknwHLfQetEqyB8=.1bfca408-a3ee-47ad-90eb-ac2d14b128ad@github.com>

On Mon, 6 Nov 2023 07:30:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

src/java.base/share/classes/java/lang/classfile/Signature.java line 219:

> 217:                  * no wildcard (empty), an exact type
> 218:                  */
> 219:                 DEFAULT,

I?m?personally in?favour of?naming this?`NONE`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1451876203

From aturbanov at openjdk.org  Mon Jan 15 07:34:21 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 07:34:21 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
Message-ID: <iF6X2pMUR6hNZa8TbgL-UfBEdEZ6RjVV1whUk6IYMC4=.0deb21bf-ec9e-4bec-8284-1bdeb2d8fdd6@github.com>

On Fri, 12 Jan 2024 15:06:01 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   timed offer

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 1162:

> 1160:         Objects.requireNonNull(e);
> 1161:         xfer(e, -1L);
> 1162:         return true;    }

Suggestion:

        return true;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17393#discussion_r1452006853

From aturbanov at openjdk.org  Mon Jan 15 07:37:22 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 07:37:22 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v6]
In-Reply-To: <vv6b9UyJVc1a4LutL5B8ymMNGjsRlW0yd5GSwSQfgRs=.cdee9633-619d-4ea0-a5e3-f390e6a9d30a@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <vv6b9UyJVc1a4LutL5B8ymMNGjsRlW0yd5GSwSQfgRs=.cdee9633-619d-4ea0-a5e3-f390e6a9d30a@github.com>
Message-ID: <Mq5o0hy5kG_WeRiR441BIHzAtndPn2pKmHbA8frnsWM=.c3670f71-e279-480e-bbca-e2af1aae84b2@github.com>

On Tue, 9 Jan 2024 13:30:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - updated copyright year
>  - reverted custom method slots counting in StackCounter
>  - improved and extended GenerateStackMaps benchmarks and renamed to CodeAttributeTools

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 83:

> 81:             vtis = new VerificationTypeInfo[methodType.parameterCount()];
> 82:         }
> 83:         for(int pi = 0; pi < methodType.parameterCount(); pi++) {

Suggestion:

        for (int pi = 0; pi < methodType.parameterCount(); pi++) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1452009672

From aturbanov at openjdk.org  Mon Jan 15 07:52:21 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 07:52:21 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
Message-ID: <KgCSGa8WfQJKeRvpahYfEBeS8eN3dUd445tFx32ra3g=.e04912c0-0ae0-4cb4-bf2e-0d8c0e8b1838@github.com>

On Tue, 9 Jan 2024 16:48:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using emulated variable blend E-Core optimized instruction.

test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 37:

> 35: @Fork(jvmArgsPrepend = {"--add-modules=jdk.incubator.vector", "-XX:UseAVX=2"})
> 36: public class ColumnFilterBenchmark {
> 37:     @Param({"1024","2047", "4096"})

Suggestion:

    @Param({"1024", "2047", "4096"})

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1452021322

From aturbanov at openjdk.org  Mon Jan 15 07:59:21 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 07:59:21 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v3]
In-Reply-To: <8FTG4cDptpPXorOh54YrFPxevoj78O7o0lqWroKssLM=.b2636eef-1248-4fd9-8d9d-820792592c17@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <8FTG4cDptpPXorOh54YrFPxevoj78O7o0lqWroKssLM=.b2636eef-1248-4fd9-8d9d-820792592c17@github.com>
Message-ID: <9miBZWx_lrZe-V0fNramB2rK-cz1-g-vAlYqvj0KZtM=.7b07f294-c2b2-4dd1-bf1a-e855aa56f04d@github.com>

On Tue, 2 Jan 2024 12:21:21 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once.
>> 
>> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
>> 
>> This fix is to move the closing of the wrapped stream inside the finally block.
>> 
>> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?)
>> 
>> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
>> 
>> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
>> 
>> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more extensive testing of combined write/close failure modes
>  - Don't suppress if finishException is null, mark stream as closed even when closing the wrapped stream failed

test/jdk/java/util/zip/ZipOutputStream/CloseWrappedStream.java line 47:

> 45:      */
> 46:     @Test
> 47:     public void exceptionDuringFinish()  {

Suggestion:

    public void exceptionDuringFinish() {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1452026379

From pminborg at openjdk.org  Mon Jan 15 08:01:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 08:01:47 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString
Message-ID: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>

This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.

Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.

-------------

Commit messages:
 - Add toString to PathElement

Changes: https://git.openjdk.org/jdk/pull/17417/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323601
  Stats: 62 lines in 3 files changed: 57 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17417/head:pull/17417

PR: https://git.openjdk.org/jdk/pull/17417

From pminborg at openjdk.org  Mon Jan 15 08:01:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 08:01:47 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString
In-Reply-To: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
Message-ID: <A5wvEVU_VDH7r5B8axQ2aaiATBtKkr2VALRbrD3V-2c=.cf7ffa76-7681-412c-a73b-36ae82a4faf9@github.com>

On Mon, 15 Jan 2024 07:56:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
> 
> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.

test/jdk/java/foreign/TestLayoutPaths.java line 341:

> 339:     public void testSequenceElementRangeToString() {
> 340:         PathElement e = PathElement.sequenceElement(2, 4);
> 341:         assertEquals(e.toString(), "sequence range 2 + N * 4, N >= 0");

Not sure this is the best way to express the toString for the range version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17417#discussion_r1452026599

From stefank at openjdk.org  Mon Jan 15 08:36:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Jan 2024 08:36:43 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v4]
In-Reply-To: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
Message-ID: <hhRYINzCHPfL7_yUOehkD9ze4k23CRp7digH7W2uyuY=.e6bfda21-7ea5-47ad-8628-6bce284292a0@github.com>

> 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 copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16807/files
  - new: https://git.openjdk.org/jdk/pull/16807/files/9a43b2c9..4fb2fc21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16807&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16807&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16807/head:pull/16807

PR: https://git.openjdk.org/jdk/pull/16807

From epeter at openjdk.org  Mon Jan 15 09:13:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 15 Jan 2024 09:13:15 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
Message-ID: <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>

On Tue, 9 Jan 2024 16:48:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using emulated variable blend E-Core optimized instruction.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5309:

> 5307:     assert(bt == T_LONG || bt == T_DOUBLE, "");
> 5308:     vmovmskpd(rtmp, mask, vec_enc);
> 5309:     shlq(rtmp, 5); // for 64 bit rows (4 longs)

Suggestion:

    shlq(rtmp, 5); // for 32 bit rows (4 longs)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1452098849

From aturbanov at openjdk.org  Mon Jan 15 09:17:10 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 09:17:10 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: <cAWfNqbnt6jAkQy8I_5eqov1XWyaXuGxv16B5Z9iizE=.2b7a3b8f-c204-46e0-8deb-6cb3ff80d847@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

test/jdk/java/lang/reflect/records/RecordReflectionTest.java line 175:

> 173:         var constructor = recordClass.getDeclaredConstructors()[0];
> 174:         i = 0;
> 175:         for(var p: constructor.getParameters()) {

Suggestion:

        for (var p: constructor.getParameters()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1452103551

From alanb at openjdk.org  Mon Jan 15 09:36:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 09:36:37 GMT
Subject: [jdk22] RFR: 8322818: Thread::getStackTrace can fail with
 InternalError if virtual thread is timed-parked when pinned
Message-ID: <GKajGf91IX8zY8_DIIFWNA0CIzFrFWxY5JfAEUsx_xo=.2122a74c-144f-4b8f-be63-59fd982d6736@github.com>

Clean backport of P3 issue JDK-8322818. The test was initially problematic so I have to include the test-only fixes JDK-8323002 and JDK-8323296 (doing these as follow-on or dependent PRs wouldn't guarantee that would integrate at the same time).

-------------

Commit messages:
 - JDK-8323002 and JDK-8323296
 - Backport 4db7a1c3bb6b56cc7416aa27350406da27fe04a8

Changes: https://git.openjdk.org/jdk22/pull/72/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=72&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322818
  Stats: 126 lines in 2 files changed: 123 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk22/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/72/head:pull/72

PR: https://git.openjdk.org/jdk22/pull/72

From chegar at openjdk.org  Mon Jan 15 09:49:39 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 09:49:39 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v4]
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <Vk4psY9ZDN1WS9pVK1SuefwECXQcfTH4Z4gk8NBd5aU=.42bd6f21-21a4-4565-b1bc-ec4dae27e619@github.com>

> Update LinkedTransferQueue add and put methods to not call overridable offer.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17393/files
  - new: https://git.openjdk.org/jdk/pull/17393/files/1097a6bc..22f2857c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From chegar at openjdk.org  Mon Jan 15 09:49:40 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 09:49:40 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <iF6X2pMUR6hNZa8TbgL-UfBEdEZ6RjVV1whUk6IYMC4=.0deb21bf-ec9e-4bec-8284-1bdeb2d8fdd6@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
 <iF6X2pMUR6hNZa8TbgL-UfBEdEZ6RjVV1whUk6IYMC4=.0deb21bf-ec9e-4bec-8284-1bdeb2d8fdd6@github.com>
Message-ID: <D05C5kSmx6Zmwutjkx4OihlAO2hGWTEstSuH4tk1kYg=.24fb6580-af77-4474-8d65-a5e19a241990@github.com>

On Mon, 15 Jan 2024 07:31:13 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   timed offer
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 1162:
> 
>> 1160:         Objects.requireNonNull(e);
>> 1161:         xfer(e, -1L);
>> 1162:         return true;    }
> 
> Suggestion:
> 
>         return true;
>     }

Thank you @turbanoff - accepted and committed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17393#discussion_r1452141389

From alanb at openjdk.org  Mon Jan 15 09:52:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 09:52:20 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <iiXBJ-r0vq2JJCPTB2iIV5oTi4JNmNDkO1V5CFPd_p8=.ff7b9633-f4f4-492a-8ddc-56033ba2e997@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
 <iiXBJ-r0vq2JJCPTB2iIV5oTi4JNmNDkO1V5CFPd_p8=.ff7b9633-f4f4-492a-8ddc-56033ba2e997@github.com>
Message-ID: <WOlF2LGtzVD6vNy1WwGCBB_2KLiJhkrXsJ_wVrjHSf0=.c5c8a388-df0a-4f29-89a6-adc5deea0dde@github.com>

On Mon, 15 Jan 2024 01:55:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> With my CSR hat on, JDK-8301341 should never have made the changes it did without going through a CSR request. We have been bitten by this kind of problem many times. Unless a public method is specified to utilise another public method, we should never implement one public method in terms of another (non-final one) due to the overriding problem.

JDK-8301341 was a big update, a lot of refactoring to hollow out SQ and it was just an oversight that we didn't spot the methods now use an overridable method. It's something to always look out for in the collections area, just missed here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1891752374

From alanb at openjdk.org  Mon Jan 15 09:56:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 09:56:32 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <ac3QapbHWEyKS-n5raQ8m6oZ6Zi5bZV_4I0ENC5j-PI=.1db57e20-5e03-41ec-ad8a-4a5c81a845f5@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
 <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@github.com>
 <ac3QapbHWEyKS-n5raQ8m6oZ6Zi5bZV_4I0ENC5j-PI=.1db57e20-5e03-41ec-ad8a-4a5c81a845f5@github.com>
Message-ID: <kZ8dKOnO-UcXcyAnef7JKqEjdvq414XJoxGyLz9l1X4=.90263a21-1f27-448e-9823-e63cf5ebaa6e@github.com>

On Sat, 13 Jan 2024 19:46:05 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> I think the related issue should be backported too.

That update is a huge update to FJP that includes API and behavior changes, the CSR has details. Maybe the starting out here is to first see if running with the JDK 22 EA builds address the issue you are seeing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1891762543

From rgiulietti at openjdk.org  Mon Jan 15 10:20:24 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 Jan 2024 10:20:24 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
Message-ID: <yFXuwbG7sVzKvl9-_r57Q0th9QOH6IhffFbHRXjjLs4=.77468544-07c2-4638-9eb1-3b39891df21d@github.com>

On Tue, 19 Dec 2023 17:53:49 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.
>
>> You mean, in the @description annotation?
> 
> Yes.

@egahlin Are you OK with the last commit from the perspective of hotspot-jfr?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1891803118

From rgiulietti at openjdk.org  Mon Jan 15 10:23:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 Jan 2024 10:23:23 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v14]
In-Reply-To: <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <g4M9J1Of5PLgDN2oR8X8VOALPwjlqblM33yY1ceG_Oc=.bf8c4362-b88e-45dc-9b36-2f3bb0ddfdef@github.com>
Message-ID: <KBa3T5JJDPC4rlXAndcSfT5LH4Z5qJsLdzMgHKgY49w=.7bd8b294-4087-4a03-a7b7-bc50b68e9f77@github.com>

On Wed, 10 Jan 2024 18:56:45 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:
> 
>   Small space optimization.

Anybody from security wants to chime in?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1891808292

From eirbjo at openjdk.org  Mon Jan 15 10:26:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 15 Jan 2024 10:26:53 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v4]
In-Reply-To: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
Message-ID: <Airpkbb74hed7sPRNLTr7uVs5Qon5SNKCfDjMYyGJHY=.d2d39b82-4ddf-4511-898c-de0c48318277@github.com>

> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once.
> 
> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
> 
> This fix is to move the closing of the wrapped stream inside the finally block.
> 
> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?)
> 
> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
> 
> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
> 
> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/util/zip/ZipOutputStream/CloseWrappedStream.java
  
  Remove extra whitespace
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17209/files
  - new: https://git.openjdk.org/jdk/pull/17209/files/33e7756e..96deca07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17209&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17209&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17209/head:pull/17209

PR: https://git.openjdk.org/jdk/pull/17209

From mcimadamore at openjdk.org  Mon Jan 15 10:42:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Jan 2024 10:42:21 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString
In-Reply-To: <A5wvEVU_VDH7r5B8axQ2aaiATBtKkr2VALRbrD3V-2c=.cf7ffa76-7681-412c-a73b-36ae82a4faf9@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <A5wvEVU_VDH7r5B8axQ2aaiATBtKkr2VALRbrD3V-2c=.cf7ffa76-7681-412c-a73b-36ae82a4faf9@github.com>
Message-ID: <D6s_rJGhF8NUdwSk6zr-lIeqewgs8Pd-FAtClSYj8gE=.1a50670b-623e-4753-9bb2-e179608580d0@github.com>

On Mon, 15 Jan 2024 07:57:00 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
>> 
>> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.
>
> test/jdk/java/foreign/TestLayoutPaths.java line 341:
> 
>> 339:     public void testSequenceElementRangeToString() {
>> 340:         PathElement e = PathElement.sequenceElement(2, 4);
>> 341:         assertEquals(e.toString(), "sequence range 2 + N * 4, N >= 0");
> 
> Not sure this is the best way to express the toString for the range version.

I think there's some choices here. One way possible way to think about paths is to imagine the consequences of chaining the strings. In the proposed implementation, this would yield very good/hard to parse results, I think.

Another way would be to borrow some C syntax, to make it look more like an access expression, so that we we can see something like:


a.b[23].c[].d->e


That said, while the above looks nice to read, it's probably hard to generate, because when printing out a single element we don't know whether e.g. to emit `.` or `->` (as a separator).

But, we could still take some inspiration from that, and have the following string representations:

* `a`
* `b[23]`
* `c[]`
* `d`
* `*e`

Then if a client chains everything, they can use e.g. `/` (or `.`) as a delimiter and it will print out something sensible and compact.

Back to your question, for the sequence range expression we can use a Numpy-style syntax:

`<start index> : <step>`

So, in this case:

`[2:4]`

Which is, again, relatively compact and "composable".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17417#discussion_r1452210277

From vklang at openjdk.org  Mon Jan 15 11:36:30 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 15 Jan 2024 11:36:30 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <ac3QapbHWEyKS-n5raQ8m6oZ6Zi5bZV_4I0ENC5j-PI=.1db57e20-5e03-41ec-ad8a-4a5c81a845f5@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
 <sDhLafs8yHy2X0tVPRLL3V-Ev3d3-bAd_eEwp11B5NE=.265d2974-e5b3-418a-82fa-70c2c4fad9cd@github.com>
 <ac3QapbHWEyKS-n5raQ8m6oZ6Zi5bZV_4I0ENC5j-PI=.1db57e20-5e03-41ec-ad8a-4a5c81a845f5@github.com>
Message-ID: <g0GzQyqkBMJrwMZCWmDp9IzYqzThysiVL8IHhuUPW-M=.92a648bf-02cc-40fb-88e5-45e1db8ea70c@github.com>

On Sat, 13 Jan 2024 19:46:05 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Cool, I just encounter this problem, when I migrate to Virtual threads and set  `jdk.virtualThreadScheduler.maxPoolSize` to 2500.
>> 
>> Will this change backport to j21u, thanks.
>
>> @He-Pin I tried to backport this patch for you just now [1]. But it can't be automatically backported because JDK-8288899 [2][3] also revised the file `src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java`. Do you want to backport these two patches? Or only this one?
>> 
>> [1] https://github.com/openjdk/jdk/commit/cc25d8b12bbab9dde9ade7762927dcb8d27e23c5#commitcomment-136982984
>> [2] https://bugs.openjdk.org/browse/JDK-8288899
>> [3] https://git.openjdk.org/jdk/pull/14301
> 
> I think the related issue should be backported too.

@He-Pin Hi He-Pin, I think @AlanBateman is right, first check if most recent 22-EA build addresses the issue you are seeing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1891996543

From asotona at openjdk.org  Mon Jan 15 12:01:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 Jan 2024 12:01:37 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v7]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <DuX77trlbQpBH1gc7PJaaEM9E3LBW2yIhEtbPQIILVs=.d0788697-b2ec-4a90-ae7f-5d7299cd255b@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/5f67f8c1..5a04ec59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17306&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17306&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17306/head:pull/17306

PR: https://git.openjdk.org/jdk/pull/17306

From chegar at openjdk.org  Mon Jan 15 12:09:48 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 12:09:48 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v5]
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <yYdheod2snRUN-xIKbWGiExvbq0OFBgVGRuUOFVRnP4=.9b59ceeb-6b5d-4fcb-af4a-2668978cba12@github.com>

> Update LinkedTransferQueue add and put methods to not call overridable offer.

Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into ltq_bug
 - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - timed offer
 - add test
 - Update LinkedTransferQueue add and put methods to not call overridable offer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17393/files
  - new: https://git.openjdk.org/jdk/pull/17393/files/22f2857c..72ad71fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=03-04

  Stats: 11818 lines in 198 files changed: 5468 ins; 5671 del; 679 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From chegar at openjdk.org  Mon Jan 15 12:09:49 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 12:09:49 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v4]
In-Reply-To: <Vk4psY9ZDN1WS9pVK1SuefwECXQcfTH4Z4gk8NBd5aU=.42bd6f21-21a4-4565-b1bc-ec4dae27e619@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <Vk4psY9ZDN1WS9pVK1SuefwECXQcfTH4Z4gk8NBd5aU=.42bd6f21-21a4-4565-b1bc-ec4dae27e619@github.com>
Message-ID: <9XiH68bqDYAo-GY29x7zMOKpiLugNdxQcH9tNj0AdSs=.f8fcb2af-cd61-46f8-a550-4d89ed561f3a@github.com>

On Mon, 15 Jan 2024 09:49:39 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

It's unfortunate that we're only discovering this now, since 21.0.2 is scheduled to release tomorrow, Jan 16th, and we've not yet gotten this reviewed and merged into _master_ or _jdk22_ yet. We can decided how to proceed with the backports once this PR has agreed the approach and is reviewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1892039902

From dl at openjdk.org  Mon Jan 15 12:37:25 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 15 Jan 2024 12:37:25 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v5]
In-Reply-To: <yYdheod2snRUN-xIKbWGiExvbq0OFBgVGRuUOFVRnP4=.9b59ceeb-6b5d-4fcb-af4a-2668978cba12@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <yYdheod2snRUN-xIKbWGiExvbq0OFBgVGRuUOFVRnP4=.9b59ceeb-6b5d-4fcb-af4a-2668978cba12@github.com>
Message-ID: <vwoDI4FkUb9mqsfNOTHW0vO4iIba1sSAURfpAm4oJ_I=.5626f958-7af3-488d-9d2a-cf35b1797b6d@github.com>

On Mon, 15 Jan 2024 12:09:48 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into ltq_bug
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - timed offer
>  - add test
>  - Update LinkedTransferQueue add and put methods to not call overridable offer

Sorry for needlessly calling overridable versions in these two cases. I should have caught that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1892095964

From duke at openjdk.org  Mon Jan 15 13:03:35 2024
From: duke at openjdk.org (He-Pin (kerr))
Date: Mon, 15 Jan 2024 13:03:35 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: <hPjHZMn6VDsQzTxRDr3GTrbs2THvqHulW6HfLsd1CNU=.320bfd7e-4d5a-4c8c-8d02-379d24282dd9@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

Thanks I will report back once I tested it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1892134621

From egahlin at openjdk.org  Mon Jan 15 13:26:25 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 15 Jan 2024 13:26:25 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>
Message-ID: <rprJpWBWz5iqcQKigB8oUTryMeijWmWKuCP0wKXSlvI=.f21f1a6f-76de-47ae-9c9a-3c6eeda54ae6@github.com>

On Tue, 19 Dec 2023 17:53:49 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.
>
>> You mean, in the @description annotation?
> 
> Yes.

> @egahlin Are you OK with the last commit from the perspective of hotspot-jfr?

The JFR product code looks fine. 

I think the test could be simplified. There is no need to disable threshold or stack trace.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1892171443

From ihse at openjdk.org  Mon Jan 15 13:30:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Jan 2024 13:30:21 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign
In-Reply-To: <KAFMo9ebt4Lh5sRAqV5rdUbbqhWPYDJJQ_R9UjMqbe8=.157b9c1a-58a9-4412-9950-119f5a73b3ee@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
 <MtsPgVmBNjn9nfy9YkEGsnCs8PYVRuVlxZmfaa7YirY=.b4929117-6436-444a-9805-756f1ecf6648@github.com>
 <KAFMo9ebt4Lh5sRAqV5rdUbbqhWPYDJJQ_R9UjMqbe8=.157b9c1a-58a9-4412-9950-119f5a73b3ee@github.com>
Message-ID: <7IXs5Iv1atdt6oh_2Q0oXuq7LZI0AoEvoIfl2sJa5bk=.96edfb45-e4b9-4bea-aeae-758a06f5152f@github.com>

On Sun, 14 Jan 2024 04:07:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> make/modules/java.base/Java.gmk line 41:
>> 
>>> 39:     java/lang/classfile/snippet-files \
>>> 40:     java/lang/classfile/components/snippet-files \
>>> 41:     jdk/lang/foreign/snippet-files
>> 
>> I can't find this directory in the source tree, but there is a `src/java.base/share/classes/java/lang/foreign/snippet-files`. Is that what you want to exclude?
>
> If possible, we should simply exclude all files in directories that have `-` (minus sign) in their name; this is the intentional design to prevent javac from compiling those classes as package names cannot include `-`.

I agree that this piecemeal approach is not good. I think there is a JBS enhancement request to filter all "snippet-files" and "javadoc-files" everywhere. But maybe we can make it broader? Filtering on just `-` makes me a bit nervous though; it seems like it could unintentionally break at some point. But maybe filter out all `-files`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17403#discussion_r1452377059

From aturbanov at openjdk.org  Mon Jan 15 13:33:26 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 13:33:26 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <3m2_CQE-NHOCN20Z4LbosqwihcUCVopTgycXADInLEI=.25f797e8-e620-4f10-9da0-245a890c41de@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

test/jdk/java/lang/StringBuffer/IndexOf.java line 220:

> 218: 
> 219:     for (int x = 0; x < 1000000; x++) {
> 220:     if(make_new) {

Suggestion:

    if (make_new) {

test/jdk/java/lang/StringBuffer/IndexOf.java line 262:

> 260:       }
> 261: 
> 262:     if(make_new)

Suggestion:

    if (make_new)

test/jdk/java/lang/StringBuffer/IndexOf.java line 295:

> 293:       }
> 294: 
> 295:       if(make_new) testIndex = getRandomIndex(-100, 100);

Suggestion:

      if (make_new) testIndex = getRandomIndex(-100, 100);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1452380458
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1452380633
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1452380799

From rgiulietti at openjdk.org  Mon Jan 15 14:17:40 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 Jan 2024 14:17:40 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v15]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@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 useless event settings in test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/b76285d9..d0f16b8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=13-14

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 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 epeter at openjdk.org  Mon Jan 15 14:42:30 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 15 Jan 2024 14:42:30 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
Message-ID: <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>

On Mon, 1 Jan 2024 14:36:06 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.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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Accelerating masked sub-word gathers for AVX2 targets, this gives additional 1.5-4x speedups over existing implementation.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
>  - Removing JDK-8321648 related changes.
>  - 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.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/518ec971...de47076e

Just had a quick look at this. Is there any support for gather with different indices for each element in the vector?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1627:

> 1625:     vpsrlvd(dst, dst, xtmp, vlen_enc);
> 1626:     // Pack double word vector into byte vector.
> 1627:     vpackI2X(T_BYTE, dst, ones, xtmp, vlen_enc);

I would prefer if there was less code duplication here. I think there are just a few values which you could set to variables, and then apply for both versions.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1634:

> 1632:                                                     Register offset, XMMRegister offset_vec, XMMRegister idx_vec,
> 1633:                                                     XMMRegister xtmp1, XMMRegister xtmp2, XMMRegister xtmp3, KRegister mask,
> 1634:                                                     KRegister gmask, int vlen_enc, int vlen) {

Would you mind giving a quick summary of what the input registers are and what exactly this method does?
Why do we need to call `vgather_subword_avx3` so many times (`lane_count_subwords`)?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1757:

> 1755:     for (int i = 0; i < 4; i++) {
> 1756:       movl(rtmp, Address(idx_base, i * 4));
> 1757:       pinsrw(dst, Address(base, rtmp, Address::times_2), i);

Do I understand this right that you are basically doing this?
`dst[i*4 .. i*4 + 3] = load_8bytes(base + (idx_base + i * 4) * 2)`
But this does not look like a gather, rather like 4 adjacent loads that pack the data together into a single 8*4 byte vector.

If so, maybe you should either leave a comment, or even rename the method.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1776:

> 1774:     for (int i = 0; i < 4; i++) {
> 1775:       movl(rtmp, Address(idx_base, i * 4));
> 1776:       addl(rtmp, offset);

Can the `offset` not be added to `idx_base` before the loop?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1900:

> 1898:       vgather8b(elem_ty, xtmp3, base, idx_base, rtmp, vlen_enc);
> 1899:     } else {
> 1900:       LP64_ONLY(vgather8b_masked(elem_ty, xtmp3, base, idx_base, mask, midx, rtmp, vlen_enc));

What happens if if not `LP64_ONLY`?

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1821723578
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452399791
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452425355
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452440206
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452441071
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452443784

From epeter at openjdk.org  Mon Jan 15 14:42:32 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 15 Jan 2024 14:42:32 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
Message-ID: <xxXJyDpOXU-pmGXKB6DMBgPTAIB32AwhTKQ-kstKItg=.45abff82-c944-4958-af25-76ba7808062f@github.com>

On Mon, 15 Jan 2024 14:25:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Accelerating masked sub-word gathers for AVX2 targets, this gives additional 1.5-4x speedups over existing implementation.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
>>  - Removing JDK-8321648 related changes.
>>  - 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.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/518ec971...de47076e
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1776:
> 
>> 1774:     for (int i = 0; i < 4; i++) {
>> 1775:       movl(rtmp, Address(idx_base, i * 4));
>> 1776:       addl(rtmp, offset);
> 
> Can the `offset` not be added to `idx_base` before the loop?

Or would that require too many registers?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452453827

From pminborg at openjdk.org  Mon Jan 15 16:01:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 16:01:32 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v2]
In-Reply-To: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
Message-ID: <ZTu8tRFAFOnSQMcJ73QHSbWT02D-b0ynG2-hBDYT9m8=.db114fd6-1903-4493-976e-1ee940de55ab@github.com>

> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
> 
> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework PathElement:toString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17417/files
  - new: https://git.openjdk.org/jdk/pull/17417/files/a9c78ea8..83cf10c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=00-01

  Stats: 25 lines in 3 files changed: 2 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17417/head:pull/17417

PR: https://git.openjdk.org/jdk/pull/17417

From alanb at openjdk.org  Mon Jan 15 16:08:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 16:08:20 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v3]
In-Reply-To: <ldznYfAiW9dA7mx8lUuKsAzLp_KDo1y2VZ1_GBZFA7A=.a8d0497d-08b5-4268-a74c-c634e80380bf@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <8FTG4cDptpPXorOh54YrFPxevoj78O7o0lqWroKssLM=.b2636eef-1248-4fd9-8d9d-820792592c17@github.com>
 <ldznYfAiW9dA7mx8lUuKsAzLp_KDo1y2VZ1_GBZFA7A=.a8d0497d-08b5-4268-a74c-c634e80380bf@github.com>
Message-ID: <pa1yM8z38cFjjgoE50_LlcKU32NY6JyHSxHYcbS0MCk=.3d934900-e117-4323-9a07-53469b911210@github.com>

On Tue, 2 Jan 2024 22:06:36 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> A CSR for this change has been proposed and is ready for review: [JDK-8322871](https://bugs.openjdk.org/browse/JDK-8322871)

I've reviewed the CSR so you can finalize. The implementation change looks fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17209#issuecomment-1892440727

From pminborg at openjdk.org  Mon Jan 15 16:10:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 16:10:30 GMT
Subject: Integrated: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
In-Reply-To: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
Message-ID: <kkuhzljO2W-bvZBNmpXVBfdYXcetSWj_md4mZZd7ODk=.7bfe9b47-c49d-43ed-acd5-e3b23f4aee43@github.com>

On Mon, 8 Jan 2024 16:16:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
> 
> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.

This pull request has now been integrated.

Changeset: f5b757ce
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5b757ced6b672010ea10575d644d3f9d1728923
Stats:     51 lines in 2 files changed: 49 ins; 0 del; 2 mod

8323159: Consider adding some text re. memory zeroing in Arena::allocate

Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/17308

From shade at openjdk.org  Mon Jan 15 16:13:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Jan 2024 16:13:34 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots
Message-ID: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>

Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 

Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.


% make test TEST=all

Test selection 'all', will run:
* jtreg:test/hotspot/jtreg:all
* jtreg:test/jdk:all
* jtreg:test/langtools:all
* jtreg:test/jaxp:all
* jtreg:test/lib-test:all

(...about 6 hours later...)

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
   jtreg:test/langtools:all                           4469  4469     0     0   
   jtreg:test/jaxp:all                                 513   513     0     0   
   jtreg:test/lib-test:all                              32    32     0     0   
==============================
TEST FAILURE

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/17422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17422&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323515
  Stats: 41 lines in 5 files changed: 34 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17422/head:pull/17422

PR: https://git.openjdk.org/jdk/pull/17422

From redestad at openjdk.org  Mon Jan 15 16:13:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 Jan 2024 16:13:37 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <_Lm9krEfbPm90RNhG6N0hNo9QbL-3HXvNZBlHxum5rM=.45f90d39-047b-4851-8f67-3ce4e5babec5@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

I'd very much welcome support for zstd, both for resource content and metadata. A larger JEP-sized project, that.

I have run a quick experiment with adding a more compact header format (16-bit sizes for the four fields) and on a `jlink --compress 2 --add-modules java.se,jdk.unsupported,jdk.management` it reduces the jimage size by about 0.9% (33279195 vs 32983412 bytes). Throughput might take a small hit. I'm not sure I have time right now to get tested and PR'd but I'll post the draft after sponsoring this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892445590

From duke at openjdk.org  Mon Jan 15 16:13:38 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 15 Jan 2024 16:13:38 GMT
Subject: Integrated: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <oGBTaVGKaVmqkGo8HtFDD0sxi9pcB5vveOtcRqXo6f4=.3e120969-4d50-4ca7-b47a-4e56cdad9c47@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

This pull request has now been integrated.

Changeset: a03eb6d3
Author:    Glavo <zjx001202 at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a03eb6d3f69301616faf13d68be8571a037e5999
Stats:     21 lines in 1 file changed: 10 ins; 5 del; 6 mod

8321620: Optimize JImage decompressors

Reviewed-by: mchung, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/17405

From pminborg at openjdk.org  Mon Jan 15 16:20:31 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 16:20:31 GMT
Subject: [jdk22] RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate
Message-ID: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>

8323159: Consider adding some text re. memory zeroing in Arena::allocate

-------------

Commit messages:
 - Backport f5b757ced6b672010ea10575d644d3f9d1728923

Changes: https://git.openjdk.org/jdk22/pull/77/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=77&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323159
  Stats: 51 lines in 2 files changed: 49 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk22/pull/77.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/77/head:pull/77

PR: https://git.openjdk.org/jdk22/pull/77

From alanb at openjdk.org  Mon Jan 15 16:26:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 16:26:20 GMT
Subject: [jdk22] RFR: 8323159: Consider adding some text re. memory zeroing
 in Arena::allocate
In-Reply-To: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
References: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
Message-ID: <jtv5zyv6dAM9qnHHllLtqvuayUeGozcJ4r-YJmDwZkA=.1082e8bc-79ae-4afe-afd1-4e7a4394a264@github.com>

On Mon, 15 Jan 2024 16:14:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> 8323159: Consider adding some text re. memory zeroing in Arena::allocate

test/jdk/java/foreign/TestScope.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2024 Oracle and/or its affiliates. All rights reserved.

Can you hold off on this until TestScope.java's copyright header is fixed in main line.

-------------

PR Review Comment: https://git.openjdk.org/jdk22/pull/77#discussion_r1452570361

From egahlin at openjdk.org  Mon Jan 15 16:30:24 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 15 Jan 2024 16:30:24 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v15]
In-Reply-To: <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
Message-ID: <AWTrYof-sFDoNiVL6F4IC3_TDUCgkYNpOrc_LvPGPtw=.9913fc61-9e23-445c-b5b3-2a7dcce451e8@github.com>

On Mon, 15 Jan 2024 14:17:40 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 useless event settings in test.

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17129#pullrequestreview-1821998747

From pminborg at openjdk.org  Mon Jan 15 16:33:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 16:33:47 GMT
Subject: Integrated: 8323745: Missing comma in copyright header in TestScope
Message-ID: <2ggpIql7GHVcoQkt_6aXq1DlGnyHABzRi9-NFgT-EsE=.c68f924d-548d-483f-a472-5f53e22fae63@github.com>

This PR proposed to fix a missing comma in the header of TestScope

-------------

Commit messages:
 - Add missing comma in copyright header

Changes: https://git.openjdk.org/jdk/pull/17431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323745
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17431/head:pull/17431

PR: https://git.openjdk.org/jdk/pull/17431

From alanb at openjdk.org  Mon Jan 15 16:33:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 16:33:47 GMT
Subject: Integrated: 8323745: Missing comma in copyright header in
 TestScope
In-Reply-To: <2ggpIql7GHVcoQkt_6aXq1DlGnyHABzRi9-NFgT-EsE=.c68f924d-548d-483f-a472-5f53e22fae63@github.com>
References: <2ggpIql7GHVcoQkt_6aXq1DlGnyHABzRi9-NFgT-EsE=.c68f924d-548d-483f-a472-5f53e22fae63@github.com>
Message-ID: <cRqreqn9RChRZVJDU-_u5wIkiKt0dBwAik0tEdpur_I=.825d036e-78f8-4faf-b76b-c609baa95776@github.com>

On Mon, 15 Jan 2024 16:25:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to fix a missing comma in the header of TestScope

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17431#pullrequestreview-1821998292

From pminborg at openjdk.org  Mon Jan 15 16:33:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Jan 2024 16:33:47 GMT
Subject: Integrated: 8323745: Missing comma in copyright header in TestScope
In-Reply-To: <2ggpIql7GHVcoQkt_6aXq1DlGnyHABzRi9-NFgT-EsE=.c68f924d-548d-483f-a472-5f53e22fae63@github.com>
References: <2ggpIql7GHVcoQkt_6aXq1DlGnyHABzRi9-NFgT-EsE=.c68f924d-548d-483f-a472-5f53e22fae63@github.com>
Message-ID: <OmnRcBqqxBmdm7vB6DeeLE6kRMqt3fwsfOSvVuDCFLI=.bc615533-c213-4f29-a944-718f0ea61c48@github.com>

On Mon, 15 Jan 2024 16:25:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to fix a missing comma in the header of TestScope

This pull request has now been integrated.

Changeset: edc0ebb7
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edc0ebb7803982311e96a8710e73fa920f321992
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8323745: Missing comma in copyright header in TestScope

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17431

From alanb at openjdk.org  Mon Jan 15 16:55:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 16:55:27 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
Message-ID: <t9EpWfLrz1D295riE-OdMAZi_Z_aNJ2M128UIFHFhSQ=.8ed837b0-85b6-4b1f-a580-825ce7923efe@github.com>

On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Remove trailing whitespace

I was initially concerned about this change but I think it's okay. As you say, it expands set the set of ZIP file that can be read by ZipInputStream. I've added myself as reviewer to the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1892510671

From jvernee at openjdk.org  Mon Jan 15 17:13:21 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Jan 2024 17:13:21 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v2]
In-Reply-To: <ZTu8tRFAFOnSQMcJ73QHSbWT02D-b0ynG2-hBDYT9m8=.db114fd6-1903-4493-976e-1ee940de55ab@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <ZTu8tRFAFOnSQMcJ73QHSbWT02D-b0ynG2-hBDYT9m8=.db114fd6-1903-4493-976e-1ee940de55ab@github.com>
Message-ID: <MquxdkvcIBJlp-pVsWFUBmtml73w5S3SREEyRan45KA=.c6e91302-a946-4f26-ac02-211f7620c7f8@github.com>

On Mon, 15 Jan 2024 16:01:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
>> 
>> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework PathElement:toString

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 958:

> 956:             return new LayoutPath.PathElementImpl(PathKind.DEREF_ELEMENT,
> 957:                     LayoutPath::derefElement,
> 958:                     "*");

It seems that this would result in paths like `a.b*` rather than the `*a.b`, which is correct C syntax.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17417#discussion_r1452611709

From chegar at openjdk.org  Mon Jan 15 17:42:20 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 17:42:20 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v5]
In-Reply-To: <vwoDI4FkUb9mqsfNOTHW0vO4iIba1sSAURfpAm4oJ_I=.5626f958-7af3-488d-9d2a-cf35b1797b6d@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <yYdheod2snRUN-xIKbWGiExvbq0OFBgVGRuUOFVRnP4=.9b59ceeb-6b5d-4fcb-af4a-2668978cba12@github.com>
 <vwoDI4FkUb9mqsfNOTHW0vO4iIba1sSAURfpAm4oJ_I=.5626f958-7af3-488d-9d2a-cf35b1797b6d@github.com>
Message-ID: <4c8P-gEg6p7564wQYc7vTBzso9q3mrgFvS7hkkar1V0=.fb440d04-86ed-48da-8767-24eef836a043@github.com>

On Mon, 15 Jan 2024 12:34:57 GMT, Doug Lea <dl at openjdk.org> wrote:

> Sorry for needlessly calling overridable versions in these two cases. I should have caught that.

No problem, easy to overlook. I assume you are ok with the changes? If so, could I please ask you to add your review. Otherwise, is there another way that we should proceed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1892569945

From alanb at openjdk.org  Mon Jan 15 17:53:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 17:53:23 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v5]
In-Reply-To: <yYdheod2snRUN-xIKbWGiExvbq0OFBgVGRuUOFVRnP4=.9b59ceeb-6b5d-4fcb-af4a-2668978cba12@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <yYdheod2snRUN-xIKbWGiExvbq0OFBgVGRuUOFVRnP4=.9b59ceeb-6b5d-4fcb-af4a-2668978cba12@github.com>
Message-ID: <2LZJkfUuJ3aa16P4csszLESryGkeO7dIookRFM-jTXk=.72694b2b-526d-4ac8-a84d-941a5b9ebeb2@github.com>

On Mon, 15 Jan 2024 12:09:48 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into ltq_bug
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - timed offer
>  - add test
>  - Update LinkedTransferQueue add and put methods to not call overridable offer

Marked as reviewed by alanb (Reviewer).

test/jdk/java/util/concurrent/LinkedTransferQueue/SubclassTest.java line 28:

> 26:  * @run testng SubclassTest
> 27:  * @bug 8323659
> 28:  * @summary Ensures that the implementation of LTQ add and put methods does

[ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER)

-------------

PR Review: https://git.openjdk.org/jdk/pull/17393#pullrequestreview-1822096706
PR Review Comment: https://git.openjdk.org/jdk/pull/17393#discussion_r1452638878

From alanb at openjdk.org  Mon Jan 15 17:56:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 17:56:28 GMT
Subject: [jdk22] RFR: 8322846: Running with -Djdk.tracePinnedThreads set can
 hang
Message-ID: <aFeN32RoMKxmclN7hKKbuD8GwJsNWlKjtcRsQvQVhZw=.e9f10359-b6c4-418c-a7ed-5490719e944e@github.com>

Clean backport of P3 issue JDK-8322846.

-------------

Commit messages:
 - Backport faa9c6909dda635eb008b9dada6e06fca47c17d6

Changes: https://git.openjdk.org/jdk22/pull/71/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=71&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322846
  Stats: 128 lines in 3 files changed: 100 ins; 12 del; 16 mod
  Patch: https://git.openjdk.org/jdk22/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/71/head:pull/71

PR: https://git.openjdk.org/jdk22/pull/71

From chegar at openjdk.org  Mon Jan 15 17:59:38 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 17:59:38 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v6]
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <7CPIl1cFgNg6WFccNox8cOPgF8C_pACtOfEgbvNGPgY=.719e622d-3e52-4490-9fa3-a4bc8bdd1a6f@github.com>

> Update LinkedTransferQueue add and put methods to not call overridable offer.

Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into ltq_bug
 - order of tags
 - Merge branch 'master' into ltq_bug
 - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - timed offer
 - add test
 - Update LinkedTransferQueue add and put methods to not call overridable offer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17393/files
  - new: https://git.openjdk.org/jdk/pull/17393/files/72ad71fb..3aa026fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=04-05

  Stats: 350 lines in 17 files changed: 297 ins; 37 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From liach at openjdk.org  Mon Jan 15 18:00:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Jan 2024 18:00:30 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v9]
In-Reply-To: <T6XBH6CjII7HTsLbIoTK-Ly1Cm6JsWVr-nUBgNb5408=.cdb3d02d-a919-432c-928e-2db76f6f15e2@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <nUxCWqXBbfxXKWnOpQ9aEqXAz3GInytnmLBi_pSnsqI=.8ccaf3ed-426b-4859-82ac-66e06243c09f@github.com>
 <T6XBH6CjII7HTsLbIoTK-Ly1Cm6JsWVr-nUBgNb5408=.cdb3d02d-a919-432c-928e-2db76f6f15e2@github.com>
Message-ID: <T807cPhIWirNToF6XCiTbYEiWpK7Kf0R-Qf3Gokcs24=.c5bdea10-1f15-41e3-be0e-af9b4de800a5@github.com>

On Thu, 21 Sep 2023 11:46:19 GMT, Adam Sotona <asotona 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 14 commits:
>> 
>>  - 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>
>>  - Merge branch 'master' into invoke-test-classfile
>>  - Fix LambdaStackTrace after running
>>  - formatting
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/526dba1a...d0b6c2ae
>
> I would integrate conversions that are ready, otherwise the work spend to fix and reflect changes would double in the preview branch.

Keep alive, @asotona can you review this again as it's up-to-date against current master's Classfile API? (i.e. without the instruction renames)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1892590106

From dl at openjdk.org  Mon Jan 15 18:14:23 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 15 Jan 2024 18:14:23 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v6]
In-Reply-To: <7CPIl1cFgNg6WFccNox8cOPgF8C_pACtOfEgbvNGPgY=.719e622d-3e52-4490-9fa3-a4bc8bdd1a6f@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <7CPIl1cFgNg6WFccNox8cOPgF8C_pACtOfEgbvNGPgY=.719e622d-3e52-4490-9fa3-a4bc8bdd1a6f@github.com>
Message-ID: <YhR0flvNM8OrbHlhW64Sd_giGdY-EpaEqT_D84-XG0Y=.7d164c19-5fc5-401d-9def-ed82cae60651@github.com>

On Mon, 15 Jan 2024 17:59:38 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into ltq_bug
>  - order of tags
>  - Merge branch 'master' into ltq_bug
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - timed offer
>  - add test
>  - Update LinkedTransferQueue add and put methods to not call overridable offer

Yes, the change looks right to me -- changing the only two calls that could matter here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1892605207

From davidalayachew at gmail.com  Mon Jan 15 18:19:13 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 15 Jan 2024 13:19:13 -0500
Subject: New method on java.util.function.Function -- ternary method
In-Reply-To: <CAA9v-_N3yUR+QPic3vjAtsbj3SkxaW4svhXP93xxtfB+yU+W4g@mail.gmail.com>
References: <CAA9v-_OO2EkG_oS3YTFQi85e04pnfJKHnzfAi0XbHv91n7Uu7w@mail.gmail.com>
 <CAA9v-_PQuWYCxJ1Tz7veJm9xFxJ6tqvx9avTBxU6DR3xOAGckw@mail.gmail.com>
 <CAA9v-_ObOe-buDL=SN-q36VOBrNNp1o-UPtG5gXAkZXb8Saryg@mail.gmail.com>
 <CAA9v-_M2sovP7TQE2HcWYP=v++F-Wo2NRQiGa36do1dtveMwRg@mail.gmail.com>
 <CAA9v-_N3yUR+QPic3vjAtsbj3SkxaW4svhXP93xxtfB+yU+W4g@mail.gmail.com>
Message-ID: <CAA9v-_PfSRFZt8EwCetvcq4jkRLxQbgU2Qt3SHppF8vyEXFA9w@mail.gmail.com>

Hello Magnus,

Thank you for closing my bug! Terribly sorry to ask another favor, but
could you link the following link for traceability in the JBS submission?

https://mail.openjdk.org/pipermail/amber-dev/2024-January/008488.html

Thank you again for the time and help!
David Alayachew

On Mon, Jan 1, 2024 at 1:26?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello all,
>
> After reading through Brian Goetz's "Effect cases on Switch"
> (specifically, the "Other switch tricks" section), I have decided to not
> implement this feature after all. The fact is, switch expressions,
> especially with "when-clauses", does a better job of clarifying intent than
> this feature does. Sure, there is slightly more verbosity, but the intent
> of this feature was never to minimize the character count, it was to
> increase clarity. And as is, switch expressions with when clauses
> accomplish that better.
>
> Here is a link to the subsection of the abovementioned article --
> https://inside.java/2023/12/15/switch-case-effect/#other-switch-tricks
>
> Could someone help me close this on JBS? Or should it just not be closed
> at all?
>
> Here is a link to the JBS -- https://bugs.openjdk.org/browse/JDK-8319802
>
> Thank you for your time and help!
> David Alayachew
>
> On Thu, Nov 9, 2023 at 1:19?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Oh, I will also add a specialized version of this method to
>> java.util.function.UnaryOperator. That is because UnaryOperator is a
>> subinterface of Function. Function goes T -> R, but UnaryOperator just goes
>> T -> T. We do not want UnaryOperator to have the T -> R static function
>> included due to inheritance, so it will get its own version that has the
>> same method name and parameters, but the type parameters will be different.
>>
>> Here is another mockup - this time for UnaryOperator2's version of the
>> same method.
>>
>> > interface UnaryOperator2<T> extends Function2<T,T>, UnaryOperator<T>
>> > {
>> >
>> >     public static <T> UnaryOperator2<T> ternaryApply
>> >     (
>> >         Predicate<? super T> test,
>> >         Function<? super T, ? extends T> trueFunction,
>> >         Function<? super T, ? extends T> falseFunction
>> >     )
>> >     {
>> >
>> >         return
>> >             (T input) ->
>> >                 test.test(input)
>> >                     ? trueFunction.apply(input)
>> >                     : falseFunction.apply(input)
>> >                     ;
>> >
>> >     }
>> >
>> > }
>>
>> On Thu, Nov 9, 2023 at 12:12?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> It has been a month since I sent this proposal. Since no one has told me
>>> that this is a terrible idea, I will submit this as an enhancement to JBS,
>>> and once the ticket is made, start work on creating a pull request.
>>>
>>> On Tue, Oct 3, 2023 at 3:13?AM David Alayachew <davidalayachew at gmail.com>
>>> wrote:
>>>
>>>> Whoops, bad import.
>>>>
>>>> Please replace the following line with the one after it.
>>>>
>>>> > import java.util.function.Function;
>>>>
>>>> > import java.util.function.*;
>>>>
>>>> On Tue, Oct 3, 2023 at 3:09?AM David Alayachew <
>>>> davidalayachew at gmail.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I have an idea that I want to run by you all -- a new method on
>>>>> java.util.function.Function to capture ternary operations.
>>>>>
>>>>> Here is a mockup of what I wanted to do.
>>>>>
>>>>> >
>>>>> > import java.util.function.Function;
>>>>> >
>>>>> > @FunctionalInterface
>>>>> > public interface Function2<I, O> extends Function<I, O>
>>>>> > {
>>>>> >
>>>>> >    public static <I, O> Function<I, O> ternary
>>>>> >    (
>>>>> >        Predicate<I> test,
>>>>> >        Function<I, O> trueOutput,
>>>>> >        Function<I, O> falseOutput
>>>>> >    )
>>>>> >    {
>>>>> >
>>>>> >       return
>>>>> >           (I input) ->
>>>>> >               test.test(input)
>>>>> >               ? trueOutput.apply(input)
>>>>> >               : falseOutput.apply(input)
>>>>> >               ;
>>>>> >
>>>>> >    }
>>>>> >
>>>>> > }
>>>>> >
>>>>>
>>>>> I think this is useful for a few reasons.
>>>>>
>>>>>  * This composes, just like the ternary operator itself.
>>>>>
>>>>>  * It pairs well with Function.identity() and method references to
>>>>> clearly (but concisely) communicate intent.
>>>>>
>>>>>  * Ternary operations are common, so this will find great use by
>>>>> developers of all sorts.
>>>>>
>>>>> There is at least one part I don't quite like about this design - what
>>>>> if one (or both!) of your outputs is not a functional transformation of the
>>>>> input?
>>>>>
>>>>> For example, String username = id.isBlank() ? "UNKNOWN" : lookup(id);
>>>>>
>>>>> Obviously, this is easy to work around - simply ignore the input of
>>>>> the function. But you lose clarity and simplicity that way. I would put a
>>>>> note in the javadoc that says that this method should only be used in
>>>>> instances where both outputs are a functional transformation of the input.
>>>>> That way, intent is clarified. But if we go that route, maybe this function
>>>>> should get a better name to capture that? testThenApply? ternaryTransform?
>>>>> ternaryApply?
>>>>>
>>>>> Thank you for your time and help!
>>>>> David Alayachew
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240115/989be71c/attachment-0001.htm>

From alanb at openjdk.org  Mon Jan 15 19:16:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Jan 2024 19:16:22 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v6]
In-Reply-To: <7CPIl1cFgNg6WFccNox8cOPgF8C_pACtOfEgbvNGPgY=.719e622d-3e52-4490-9fa3-a4bc8bdd1a6f@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <7CPIl1cFgNg6WFccNox8cOPgF8C_pACtOfEgbvNGPgY=.719e622d-3e52-4490-9fa3-a4bc8bdd1a6f@github.com>
Message-ID: <y2TfGu5Lm8c5CcQZvKAoTanYe5YwpHpHTWfTgYoaUB0=.005c7431-4871-4e44-ba96-2a2f663eec35@github.com>

On Mon, 15 Jan 2024 17:59:38 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into ltq_bug
>  - order of tags
>  - Merge branch 'master' into ltq_bug
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - timed offer
>  - add test
>  - Update LinkedTransferQueue add and put methods to not call overridable offer

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17393#pullrequestreview-1822167659

From redestad at openjdk.org  Mon Jan 15 19:31:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 Jan 2024 19:31:25 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <aqUMG-JjWM1UX42kAtjXVzo3bVYeR0I11oDSvMMTEUA=.2a6feb74-702c-4d86-b558-8cd029bfb730@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

For reference here's my draft idea on a backwards-compatible compressed compressed header (heh): https://github.com/openjdk/jdk/pull/17433

No significant difference on micros but a modest saving on the archive size.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892678919

From duke at openjdk.org  Mon Jan 15 22:19:25 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 15 Jan 2024 22:19:25 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <_Lm9krEfbPm90RNhG6N0hNo9QbL-3HXvNZBlHxum5rM=.45f90d39-047b-4851-8f67-3ce4e5babec5@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
 <_Lm9krEfbPm90RNhG6N0hNo9QbL-3HXvNZBlHxum5rM=.45f90d39-047b-4851-8f67-3ce4e5babec5@github.com>
Message-ID: <Ao39eJ1DCQRUqnCNhn87kpm39lYzK7dm0btjc_fxPm0=.fe37a326-ed19-4983-b384-7207c5323e36@github.com>

On Mon, 15 Jan 2024 16:08:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'd very much welcome support for zstd, both for resource content and metadata. A larger JEP-sized project, that.
> 
> I have run a quick experiment with adding a more compact header format (16-bit sizes for the four fields) and on a `jlink --compress 2 --add-modules java.se,jdk.unsupported,jdk.management` it reduces the jimage size by about 0.9% (33279195 vs 32983412 bytes). Throughput might take a small hit. I'm not sure I have time right now to get tested and PR'd but I'll post the draft after sponsoring this.

>From my experience on the JApp project, if compressed metadata is implemented, the size of these fields may be irrelevant.

In the early development stage of JApp, I used 32-bit integers to store metadata such as resource size. But after using zstd to compress the metadata, I was surprised to find that storing them as 64-bit integers can actually reduce the file size for some test cases. The compression algorithm does the work for me, so I no longer need to care about these details.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892821541

From dholmes at openjdk.org  Mon Jan 15 22:41:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 22:41:24 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>

On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

Okay - change is harmless with no ongoing maintenance cost.

test/jdk/TEST.groups line 28:

> 26: #
> 27: 
> 28: all = \

Why no `jdk_all` definition in this case?

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1822313872
PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1452781088

From chegar at openjdk.org  Mon Jan 15 22:43:23 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 15 Jan 2024 22:43:23 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <WOlF2LGtzVD6vNy1WwGCBB_2KLiJhkrXsJ_wVrjHSf0=.c5c8a388-df0a-4f29-89a6-adc5deea0dde@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
 <iiXBJ-r0vq2JJCPTB2iIV5oTi4JNmNDkO1V5CFPd_p8=.ff7b9633-f4f4-492a-8ddc-56033ba2e997@github.com>
 <WOlF2LGtzVD6vNy1WwGCBB_2KLiJhkrXsJ_wVrjHSf0=.c5c8a388-df0a-4f29-89a6-adc5deea0dde@github.com>
Message-ID: <xiyBNgTKqx9z8yFX3kWWti1nw-Dx1ZY8xti2bK6f95A=.48397109-9a6f-4cff-8182-eb590e86cc9b@github.com>

On Mon, 15 Jan 2024 09:49:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With my CSR hat on, JDK-8301341 should never have made the changes it did without going through a CSR request. We have been bitten by this kind of problem many times. Unless a public method is specified to utilise another public method, we should never implement one public method in terms of another (non-final one) due to the overriding problem. Backporting such a change to 21u is then potentially very damaging.
>
>> With my CSR hat on, JDK-8301341 should never have made the changes it did without going through a CSR request. We have been bitten by this kind of problem many times. Unless a public method is specified to utilise another public method, we should never implement one public method in terms of another (non-final one) due to the overriding problem.
> 
> JDK-8301341 was a big update, a lot of refactoring to hollow out SQ and it was just an oversight that we didn't spot the methods now use an overridable method. It's something to always look out for in the collections area, just missed here.

Thanks for the reviews @AlanBateman and @DougLea

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1892838717

From duke at openjdk.org  Mon Jan 15 22:43:29 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 15 Jan 2024 22:43:29 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <Ao39eJ1DCQRUqnCNhn87kpm39lYzK7dm0btjc_fxPm0=.fe37a326-ed19-4983-b384-7207c5323e36@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
 <_Lm9krEfbPm90RNhG6N0hNo9QbL-3HXvNZBlHxum5rM=.45f90d39-047b-4851-8f67-3ce4e5babec5@github.com>
 <Ao39eJ1DCQRUqnCNhn87kpm39lYzK7dm0btjc_fxPm0=.fe37a326-ed19-4983-b384-7207c5323e36@github.com>
Message-ID: <X6G3Tot7fcrhcLWcNkhB8mVrQ25wOtEu4Hj8tazf21I=.cebd3d44-72c9-4225-b02c-e8ee8a63a671@github.com>

On Mon, 15 Jan 2024 22:16:13 GMT, Glavo <duke at openjdk.org> wrote:

> In the early development stage of JApp, I used 32-bit integers to store metadata such as resource size. But after using zstd to compress the metadata, I was surprised to find that storing them as 64-bit integers can actually reduce the file size for some test cases.

Sorry, I re-looked at the test data and found that I was wrong. Switching 32-bit fields to 64-bit still slightly increased the file size, although I still feel this is inconsequential.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892838446

From redestad at openjdk.org  Mon Jan 15 23:52:26 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 Jan 2024 23:52:26 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
References: <BRWGu7IW1UMu3a7S6yRnGXt2FQ2xu7xuKg0IvDY5yG0=.f8a53d0d-f195-459e-a270-289a7f1d613f@github.com>
Message-ID: <pGR3m-dG_CDvwxImBhZm-ck3dSzYNe5G0hg9RdN6oAY=.4da4cdfe-04b6-4d43-b776-c0074a06487e@github.com>

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 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:
> 
> 
> 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 70% while decompression speed is significantly improved.

It'd be very interesting to see zstd compression applied in this context to see how it'd stack up w.r.t archive size, speed of decompression and so on. 

In this specific case we'd probably have to keep the 4-byte magic marker intact (it might be possible to rid us of this), then compress the remainder (25 bytes) and store the size (a byte might be enough). For reference with regular zip on representative data I can squeeze headers down then from 29 to 22-24 bytes. In #17433 I'm down to 12 bytes (including marker) with little to no overhead. I'm not going to pursue getting #17433 integrated (for now), but it might be a nice little piece of a larger puzzle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892883726

From duke at openjdk.org  Tue Jan 16 00:56:31 2024
From: duke at openjdk.org (duke)
Date: Tue, 16 Jan 2024 00:56:31 GMT
Subject: Withdrawn: 8320400: Make fields final in 'jdk.internal.util.xml.impl'
 package
In-Reply-To: <AGr08tvla4N8-3_LAE2CKNI3elG-IVVfOUq5BIsk0QU=.b6a6e30c-12e6-47cb-af7f-cffc446020d7@github.com>
References: <AGr08tvla4N8-3_LAE2CKNI3elG-IVVfOUq5BIsk0QU=.b6a6e30c-12e6-47cb-af7f-cffc446020d7@github.com>
Message-ID: <YFlxLHoGVA4vmcxxdDaQEIKOkfNh-nAYIKUKs4u7wwk=.f6990acb-9f7f-463d-b5a3-af97dfde0ba9@github.com>

On Tue, 12 Sep 2023 19:59:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `jdk.internal.util.xml.impl` package have non-final fields which could easily be marked `final`.
> 
> Also fixed a few typos and incorrect javadoc links.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15691

From jpai at openjdk.org  Tue Jan 16 01:06:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 01:06:21 GMT
Subject: [jdk22] RFR: 8322846: Running with -Djdk.tracePinnedThreads set
 can hang
In-Reply-To: <aFeN32RoMKxmclN7hKKbuD8GwJsNWlKjtcRsQvQVhZw=.e9f10359-b6c4-418c-a7ed-5490719e944e@github.com>
References: <aFeN32RoMKxmclN7hKKbuD8GwJsNWlKjtcRsQvQVhZw=.e9f10359-b6c4-418c-a7ed-5490719e944e@github.com>
Message-ID: <p4RTajluSGfrVXwM54PEXPkNbfZlyUr6Jq4yYHSF2RU=.3ff935e9-7fef-4a7d-bd78-8e6157448385@github.com>

On Sat, 13 Jan 2024 18:06:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of P3 issue JDK-8322846.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/71#pullrequestreview-1822387922

From jpai at openjdk.org  Tue Jan 16 01:09:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 01:09:24 GMT
Subject: [jdk22] RFR: 8322818: Thread::getStackTrace can fail with
 InternalError if virtual thread is timed-parked when pinned
In-Reply-To: <GKajGf91IX8zY8_DIIFWNA0CIzFrFWxY5JfAEUsx_xo=.2122a74c-144f-4b8f-be63-59fd982d6736@github.com>
References: <GKajGf91IX8zY8_DIIFWNA0CIzFrFWxY5JfAEUsx_xo=.2122a74c-144f-4b8f-be63-59fd982d6736@github.com>
Message-ID: <_SEuCt-pyXUPXQfxzMc8q8B4-Iz0htXOvYnL21KiR3A=.0529c78f-1a73-447c-b962-e1b01b342d2b@github.com>

On Sat, 13 Jan 2024 18:08:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of P3 issue JDK-8322818. The test was initially problematic so I have to include the test-only fixes JDK-8323002 and JDK-8323296 (doing these as follow-on or dependent PRs wouldn't guarantee that would integrate at the same time).

Looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/72#pullrequestreview-1822389191

From jbhateja at openjdk.org  Tue Jan 16 06:11:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 06:11:24 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
Message-ID: <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>

On Mon, 15 Jan 2024 13:49:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Accelerating masked sub-word gathers for AVX2 targets, this gives additional 1.5-4x speedups over existing implementation.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
>>  - Removing JDK-8321648 related changes.
>>  - 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.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/518ec971...de47076e
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1627:
> 
>> 1625:     vpsrlvd(dst, dst, xtmp, vlen_enc);
>> 1626:     // Pack double word vector into byte vector.
>> 1627:     vpackI2X(T_BYTE, dst, ones, xtmp, vlen_enc);
> 
> I would prefer if there was less code duplication here. I think there are just a few values which you could set to variables, and then apply for both versions.

Meaty part of the algorithm accept different operands, line #1593, #1599 and #1601, keep two flows for SHORT and BYTE separate will be better maintainable.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1634:
> 
>> 1632:                                                     Register offset, XMMRegister offset_vec, XMMRegister idx_vec,
>> 1633:                                                     XMMRegister xtmp1, XMMRegister xtmp2, XMMRegister xtmp3, KRegister mask,
>> 1634:                                                     KRegister gmask, int vlen_enc, int vlen) {
> 
> Would you mind giving a quick summary of what the input registers are and what exactly this method does?
> Why do we need to call `vgather_subword_avx3` so many times (`lane_count_subwords`)?

Method gathers sub-words from gather indices using integral gather instructions, because of the lane size mismatch b/w int and sub-words algorithm makes multiple calls to vgather_subword_avx3.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1757:
> 
>> 1755:     for (int i = 0; i < 4; i++) {
>> 1756:       movl(rtmp, Address(idx_base, i * 4));
>> 1757:       pinsrw(dst, Address(base, rtmp, Address::times_2), i);
> 
> Do I understand this right that you are basically doing this?
> `dst[i*4 .. i*4 + 3] = load_8bytes(base + (idx_base + i * 4) * 2)`
> But this does not look like a gather, rather like 4 adjacent loads that pack the data together into a single 8*4 byte vector.
> 
> Why can this not be done by a simple `32bit` load?

Loop scans over integral index array and pick the work from computed address,  indexes could be non-contiguous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452964120
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452964077
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452964030

From jbhateja at openjdk.org  Tue Jan 16 06:11:27 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 06:11:27 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <xxXJyDpOXU-pmGXKB6DMBgPTAIB32AwhTKQ-kstKItg=.45abff82-c944-4958-af25-76ba7808062f@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
 <xxXJyDpOXU-pmGXKB6DMBgPTAIB32AwhTKQ-kstKItg=.45abff82-c944-4958-af25-76ba7808062f@github.com>
Message-ID: <5G47VHfwKVS0dm89ZHHKyyvA-LV5sqTCal0E52Ocof8=.97c7f971-e20c-41af-b0b4-49aff274351d@github.com>

On Mon, 15 Jan 2024 14:36:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1776:
>> 
>>> 1774:     for (int i = 0; i < 4; i++) {
>>> 1775:       movl(rtmp, Address(idx_base, i * 4));
>>> 1776:       addl(rtmp, offset);
>> 
>> Can the `offset` not be added to `idx_base` before the loop?
>
> Or would that require too many registers?

> Can the `offset` not be added to `idx_base` before the loop?

Offset needs to be added to each index element, please refer to API specification for details.
https://docs.oracle.com/en/java/javase/21/docs/api/jdk.incubator.vector/jdk/incubator/vector/ShortVector.html#fromArray(jdk.incubator.vector.VectorSpecies,short[],int,int[],int)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452964002

From jbhateja at openjdk.org  Tue Jan 16 06:16:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 06:16:22 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
 <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>
Message-ID: <4-XrsvK-2HpBV3neMmQQ5Q1A4FDOAnmyFtCkKKZcf2A=.32df7d9e-e399-4715-a6b5-f3f2e9c77150@github.com>

On Mon, 15 Jan 2024 09:10:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using emulated variable blend E-Core optimized instruction.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5309:
> 
>> 5307:     assert(bt == T_LONG || bt == T_DOUBLE, "");
>> 5308:     vmovmskpd(rtmp, mask, vec_enc);
>> 5309:     shlq(rtmp, 5); // for 64 bit rows (4 longs)
> 
> Suggestion:
> 
>     shlq(rtmp, 5); // for 32 bit rows (4 longs)

Each long/double permute lane holds 64 bit value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1452967063

From jbhateja at openjdk.org  Tue Jan 16 06:20:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 06:20:24 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
Message-ID: <BP7uVU_mIvVu2A4JUXgQcCWCiTMP_pmEaazciQk-PHc=.2042f7bf-201e-4ea8-8013-724a30160472@github.com>

On Mon, 15 Jan 2024 14:27:43 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Accelerating masked sub-word gathers for AVX2 targets, this gives additional 1.5-4x speedups over existing implementation.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
>>  - Removing JDK-8321648 related changes.
>>  - 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.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/518ec971...de47076e
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1900:
> 
>> 1898:       vgather8b(elem_ty, xtmp3, base, idx_base, rtmp, vlen_enc);
>> 1899:     } else {
>> 1900:       LP64_ONLY(vgather8b_masked(elem_ty, xtmp3, base, idx_base, mask, midx, rtmp, vlen_enc));
> 
> What happens if if not `LP64_ONLY`?

32bit skip over check is part of match_rule_supported_vector, https://github.com/openjdk/jdk/pull/16354/files#diff-d6a3624f0f0af65a98a47378a5c146eed5016ca09b4de1acd0a3acc823242e82R1921

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1452969364

From jbhateja at openjdk.org  Tue Jan 16 06:21:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 06:21:25 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <ItRevc3juiXfmJ_cG6WjyM5CRtnaAEi-OLPU-fc1ZZ0=.682e2489-473c-4d9b-b23b-1e9c1e7cd8ef@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

label add hotspot-compiler-dev

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1893133426

From aturbanov at openjdk.org  Tue Jan 16 07:01:27 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 16 Jan 2024 07:01:27 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
Message-ID: <U77MFwXYAJw62bPGmNmdnvQXa-149k4GSNR6pltqGoY=.f0a5873a-edfb-4fc0-ad55-711ec4c7466b@github.com>

On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Remove trailing whitespace

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 657:

> 655:      * @param size  the value of the 'uncompressed size' field in the LOC
> 656:      */
> 657:     private boolean expect64BitDataDescriptor(byte[] extra, int flag, long csize, long size)  {

Suggestion:

    private boolean expect64BitDataDescriptor(byte[] extra, int flag, long csize, long size) {

test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 113:

> 111:         // This ZIP has the regular 4-bit data descriptor
> 112: 
> 113:         byte[] extra = new byte[Long.BYTES  + Long.BYTES + Short.BYTES * 2]; // Size of a regular Zip64 extra field

Suggestion:

        byte[] extra = new byte[Long.BYTES + Long.BYTES + Short.BYTES * 2]; // Size of a regular Zip64 extra field

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1452996737
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1452996515

From epeter at openjdk.org  Tue Jan 16 07:11:25 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Jan 2024 07:11:25 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <4-XrsvK-2HpBV3neMmQQ5Q1A4FDOAnmyFtCkKKZcf2A=.32df7d9e-e399-4715-a6b5-f3f2e9c77150@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
 <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>
 <4-XrsvK-2HpBV3neMmQQ5Q1A4FDOAnmyFtCkKKZcf2A=.32df7d9e-e399-4715-a6b5-f3f2e9c77150@github.com>
Message-ID: <rmE-0addbbzxDGbBwHgtovvwWCx_gxnmlfzKXdyKN4s=.73ef2a3a-ab4a-4b4a-b6a5-20f4e13ed993@github.com>

On Tue, 16 Jan 2024 06:13:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5309:
>> 
>>> 5307:     assert(bt == T_LONG || bt == T_DOUBLE, "");
>>> 5308:     vmovmskpd(rtmp, mask, vec_enc);
>>> 5309:     shlq(rtmp, 5); // for 64 bit rows (4 longs)
>> 
>> Suggestion:
>> 
>>     shlq(rtmp, 5); // for 32 bit rows (4 longs)
>
> Each long/double permute lane holds 64 bit value.

@jatin-bhateja so why do you shift by 5? I thought 4 longs are 32 bit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1453003935

From epeter at openjdk.org  Tue Jan 16 07:13:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Jan 2024 07:13:24 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <BP7uVU_mIvVu2A4JUXgQcCWCiTMP_pmEaazciQk-PHc=.2042f7bf-201e-4ea8-8013-724a30160472@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
 <BP7uVU_mIvVu2A4JUXgQcCWCiTMP_pmEaazciQk-PHc=.2042f7bf-201e-4ea8-8013-724a30160472@github.com>
Message-ID: <LMZMsRknXgIs8bpoz6v-3N9-5paEy_jTx4U0cxZ4as8=.7b6b58cd-ee27-421b-8082-f9c8e12bd5a4@github.com>

On Tue, 16 Jan 2024 06:17:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1900:
>> 
>>> 1898:       vgather8b(elem_ty, xtmp3, base, idx_base, rtmp, vlen_enc);
>>> 1899:     } else {
>>> 1900:       LP64_ONLY(vgather8b_masked(elem_ty, xtmp3, base, idx_base, mask, midx, rtmp, vlen_enc));
>> 
>> What happens if if not `LP64_ONLY`?
>
> 32bit skip over check is part of match_rule_supported_vector, https://github.com/openjdk/jdk/pull/16354/files#diff-d6a3624f0f0af65a98a47378a5c146eed5016ca09b4de1acd0a3acc823242e82R1921

An assert might still be nice. Or just call the method anyway but then hit an assert there?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1453005169

From epeter at openjdk.org  Tue Jan 16 07:24:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Jan 2024 07:24:21 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
 <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>
Message-ID: <fVmr9L8yv0tAgQtTA51WIvFJZ_0azjO5BBm9HNlw8ao=.7a7a0d24-4ca1-44e5-aad9-effa0aa5de09@github.com>

On Tue, 16 Jan 2024 06:08:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1757:
>> 
>>> 1755:     for (int i = 0; i < 4; i++) {
>>> 1756:       movl(rtmp, Address(idx_base, i * 4));
>>> 1757:       pinsrw(dst, Address(base, rtmp, Address::times_2), i);
>> 
>> Do I understand this right that you are basically doing this?
>> `dst[i*4 .. i*4 + 3] = load_8bytes(base + (idx_base + i * 4) * 2)`
>> But this does not look like a gather, rather like 4 adjacent loads that pack the data together into a single 8*4 byte vector.
>> 
>> Why can this not be done by a simple `32bit` load?
>
> Loop scans over integral index array and pick the work from computed address,  indexes could be non-contiguous.

Maybe you could have comment lines that state this, similar like in the documentation?
`dst[i] = load(base + 2 * load(idx_base + i * 4))`
Or maybe:
`dst[i] = base[idx_base[i * 4] * 2]`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1453013821

From epeter at openjdk.org  Tue Jan 16 07:28:22 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Jan 2024 07:28:22 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
 <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>
Message-ID: <Q2BQgupkAYQmFdnn43Bu1CwucAWUtMWRTMI4nlWLWXc=.cd24a7e7-eaff-46bc-b605-d392d00ce9e9@github.com>

On Tue, 16 Jan 2024 06:08:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1627:
>> 
>>> 1625:     vpsrlvd(dst, dst, xtmp, vlen_enc);
>>> 1626:     // Pack double word vector into byte vector.
>>> 1627:     vpackI2X(T_BYTE, dst, ones, xtmp, vlen_enc);
>> 
>> I would prefer if there was less code duplication here. I think there are just a few values which you could set to variables, and then apply for both versions.
>
> Meaty part of the algorithm accept different operands, line #1593, #1599 and #1601, keep two flows for SHORT and BYTE separate will be better maintainable.

All I see is replacing a 3 with a 4, etc. It just makes this very long to review, and spot the differences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1453017659

From epeter at openjdk.org  Tue Jan 16 07:34:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Jan 2024 07:34:24 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
 <x009yqXPnDZdI-oFToELIrkL09l_lRM8HlWy8jJJOaQ=.9142dd59-7229-42c8-8373-23e414943516@github.com>
Message-ID: <zoins272Nqg29KOnWe2nSNvtSQgljT-aHFvur31Allw=.adffa6e0-df8f-4ce0-a197-c6fdcd2c93fb@github.com>

On Tue, 16 Jan 2024 06:08:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1634:
>> 
>>> 1632:                                                     Register offset, XMMRegister offset_vec, XMMRegister idx_vec,
>>> 1633:                                                     XMMRegister xtmp1, XMMRegister xtmp2, XMMRegister xtmp3, KRegister mask,
>>> 1634:                                                     KRegister gmask, int vlen_enc, int vlen) {
>> 
>> Would you mind giving a quick summary of what the input registers are and what exactly this method does?
>> Why do we need to call `vgather_subword_avx3` so many times (`lane_count_subwords`)?
>
> Method gathers sub-words from gather indices using integral gather instructions, because of the lane size mismatch b/w int and sub-words algorithm makes multiple calls to vgather_subword_avx3.

As a reviewer, I feel like I have to reverse engineer this now. I would really appreciate if there was a proper comment at the beginning, that tells me what is happening here. Maybe use some equation at the beginning, of what we want to acheive in the abstract, then explain why that does not work directly, and why you have to break it down into a loop, and then state the equation again in the loop form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1453020617

From epeter at openjdk.org  Tue Jan 16 07:34:26 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Jan 2024 07:34:26 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v10]
In-Reply-To: <5G47VHfwKVS0dm89ZHHKyyvA-LV5sqTCal0E52Ocof8=.97c7f971-e20c-41af-b0b4-49aff274351d@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Zdo5MXSebBNz9u8dOUCLYxyu0l27-XYWuKR-RZShDCs=.7eab5d2f-f46f-4aae-a561-da40ce2af9ba@github.com>
 <Rzhxh_Ip7LyabDmSgq-CnOOK5DoGHIrcidGraGxkh7k=.e81237a5-a004-4cdd-b95a-57f8ba1a16c7@github.com>
 <xxXJyDpOXU-pmGXKB6DMBgPTAIB32AwhTKQ-kstKItg=.45abff82-c944-4958-af25-76ba7808062f@github.com>
 <5G47VHfwKVS0dm89ZHHKyyvA-LV5sqTCal0E52Ocof8=.97c7f971-e20c-41af-b0b4-49aff274351d@github.com>
Message-ID: <x1L92kzzHD3THow3eobfp-XXgblH0aKUAKMaaCDvdhU=.92e0a8f9-a083-4820-b1f0-b68ed0d02165@github.com>

On Tue, 16 Jan 2024 06:08:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Or would that require too many registers?
>
>> Can the `offset` not be added to `idx_base` before the loop?
> 
> Offset needs to be added to each index element, please refer to API specification for details.
> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.incubator.vector/jdk/incubator/vector/ShortVector.html#fromArray(jdk.incubator.vector.VectorSpecies,short[],int,int[],int)

Ah great, thanks for the link ? 
Can you put such equations in the code, using the register names?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1453021973

From jhendrikx at openjdk.org  Tue Jan 16 07:46:48 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Jan 2024 07:46:48 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
Message-ID: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>

Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.

-------------

Commit messages:
 - Improve putIfAbsent documentation

Changes: https://git.openjdk.org/jdk/pull/17438/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323760
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17438/head:pull/17438

PR: https://git.openjdk.org/jdk/pull/17438

From alanb at openjdk.org  Tue Jan 16 08:22:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 08:22:24 GMT
Subject: [jdk22] Integrated: 8322846: Running with -Djdk.tracePinnedThreads set
 can hang
In-Reply-To: <aFeN32RoMKxmclN7hKKbuD8GwJsNWlKjtcRsQvQVhZw=.e9f10359-b6c4-418c-a7ed-5490719e944e@github.com>
References: <aFeN32RoMKxmclN7hKKbuD8GwJsNWlKjtcRsQvQVhZw=.e9f10359-b6c4-418c-a7ed-5490719e944e@github.com>
Message-ID: <7mlyBJhwtT6DchkNnZD5uAYWLuMYB3VfjJ5g_leAWhQ=.f4b3a7a4-7731-41a1-a470-2acf132a788a@github.com>

On Sat, 13 Jan 2024 18:06:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of P3 issue JDK-8322846.

This pull request has now been integrated.

Changeset: 30172819
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/3017281956f3c8b50f064a75444c74a18d59e96d
Stats:     128 lines in 3 files changed: 100 ins; 12 del; 16 mod

8322846: Running with -Djdk.tracePinnedThreads set can hang

Reviewed-by: jpai
Backport-of: faa9c6909dda635eb008b9dada6e06fca47c17d6

-------------

PR: https://git.openjdk.org/jdk22/pull/71

From alanb at openjdk.org  Tue Jan 16 08:22:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 08:22:25 GMT
Subject: [jdk22] Integrated: 8322818: Thread::getStackTrace can fail with
 InternalError if virtual thread is timed-parked when pinned
In-Reply-To: <GKajGf91IX8zY8_DIIFWNA0CIzFrFWxY5JfAEUsx_xo=.2122a74c-144f-4b8f-be63-59fd982d6736@github.com>
References: <GKajGf91IX8zY8_DIIFWNA0CIzFrFWxY5JfAEUsx_xo=.2122a74c-144f-4b8f-be63-59fd982d6736@github.com>
Message-ID: <uTiHsEnT0h-Smcnh39heXoCeQDL1iKf1gh8-dL39Q14=.75af5cde-28ec-4e69-91d1-9062c8a96344@github.com>

On Sat, 13 Jan 2024 18:08:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Clean backport of P3 issue JDK-8322818. The test was initially problematic so I have to include the test-only fixes JDK-8323002 and JDK-8323296 (doing these as follow-on or dependent PRs wouldn't guarantee that would integrate at the same time).

This pull request has now been integrated.

Changeset: 628e31b8
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/628e31b8c1ab425fa61219439c7f7f05fe6ea883
Stats:     126 lines in 2 files changed: 123 ins; 0 del; 3 mod

8322818: Thread::getStackTrace can fail with InternalError if virtual thread is timed-parked when pinned
8323002: test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java times out on macosx-x64
8323296: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id1 timed out

Reviewed-by: jpai
Backport-of: 4db7a1c3bb6b56cc7416aa27350406da27fe04a8

-------------

PR: https://git.openjdk.org/jdk22/pull/72

From pminborg at openjdk.org  Tue Jan 16 08:47:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Jan 2024 08:47:47 GMT
Subject: [jdk22] RFR: 8323159: Consider adding some text re. memory zeroing
 in Arena::allocate [v2]
In-Reply-To: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
References: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
Message-ID: <UB4Cvt1Tuiv2_sZAdkNCaS48fuozwIzxmFQqJFk_faI=.f01497f2-e38b-4ea9-9785-783b53005b64@github.com>

> 8323159: Consider adding some text re. memory zeroing in Arena::allocate

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add missing comma in TestScope.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk22/pull/77/files
  - new: https://git.openjdk.org/jdk22/pull/77/files/45c100bb..9fa7cf85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk22&pr=77&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk22&pr=77&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/77.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/77/head:pull/77

PR: https://git.openjdk.org/jdk22/pull/77

From shade at openjdk.org  Tue Jan 16 08:54:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 08:54:46 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v2]
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <WdUxPU8N87YRubi9_SNLdaAhG0RgqvAIl4mBy9uDXqY=.efcd4142-847b-45fd-824c-813ae70e1a40@github.com>

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  jdk_all and lib_test_all groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17422/files
  - new: https://git.openjdk.org/jdk/pull/17422/files/7f6797b6..78f5f9bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17422&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17422&range=00-01

  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17422/head:pull/17422

PR: https://git.openjdk.org/jdk/pull/17422

From shade at openjdk.org  Tue Jan 16 08:54:49 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 08:54:49 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v2]
In-Reply-To: <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
Message-ID: <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>

On Mon, 15 Jan 2024 22:37:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jdk_all and lib_test_all groups
>
> test/jdk/TEST.groups line 28:
> 
>> 26: #
>> 27: 
>> 28: all = \
> 
> Why no `jdk_all` definition in this case?

Tried not to introduce new `*_all` groups here. `jdk_all` would be the same as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1453098855

From alanb at openjdk.org  Tue Jan 16 08:54:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 08:54:49 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v2]
In-Reply-To: <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
 <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>
Message-ID: <y9XkWwGo69xwDvQRpigZgw1O7FPSDvZcdxBsR40-lVA=.11eb8a35-d1c9-4685-8078-525b8adbc45e@github.com>

On Tue, 16 Jan 2024 08:47:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/TEST.groups line 28:
>> 
>>> 26: #
>>> 27: 
>>> 28: all = \
>> 
>> Why no `jdk_all` definition in this case?
>
> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new commit.

"all" looks okay but the comment "Catch-all" suggests something else, shouldn't be "All tests"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1453103766

From shade at openjdk.org  Tue Jan 16 09:01:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 09:01:35 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Catch-all -> All tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17422/files
  - new: https://git.openjdk.org/jdk/pull/17422/files/78f5f9bd..def2f39b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17422&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17422&range=01-02

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17422/head:pull/17422

PR: https://git.openjdk.org/jdk/pull/17422

From shade at openjdk.org  Tue Jan 16 09:01:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Jan 2024 09:01:36 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <y9XkWwGo69xwDvQRpigZgw1O7FPSDvZcdxBsR40-lVA=.11eb8a35-d1c9-4685-8078-525b8adbc45e@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <ZoTk1pMMvQVUd3sbP1ONxRX4b_qOWfgyw_3PGP3lrJ4=.bde44f55-1fd5-46b0-9f1a-3bfd6194d765@github.com>
 <vSyIXgmJRL8Xw7gn1lxXF73UE0pjBuK36HfbQz_0_ws=.8c1243c2-f89e-4d4b-a5cb-942462f5124e@github.com>
 <y9XkWwGo69xwDvQRpigZgw1O7FPSDvZcdxBsR40-lVA=.11eb8a35-d1c9-4685-8078-525b8adbc45e@github.com>
Message-ID: <MqemqHpjlMv17bxzrzR2lwyWYJvyk7FdQV4sRRdYWkQ=.780a562a-2608-4f9c-a431-52c2a6166c78@github.com>

On Tue, 16 Jan 2024 08:52:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new commit.
>
> "all" looks okay but the comment "Catch-all" suggests something else, shouldn't be "All tests"?

Yeah, we can do "All tests" instead. See new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17422#discussion_r1453113607

From pminborg at openjdk.org  Tue Jan 16 09:09:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Jan 2024 09:09:26 GMT
Subject: [jdk22] RFR: 8323159: Consider adding some text re. memory zeroing
 in Arena::allocate [v2]
In-Reply-To: <jtv5zyv6dAM9qnHHllLtqvuayUeGozcJ4r-YJmDwZkA=.1082e8bc-79ae-4afe-afd1-4e7a4394a264@github.com>
References: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
 <jtv5zyv6dAM9qnHHllLtqvuayUeGozcJ4r-YJmDwZkA=.1082e8bc-79ae-4afe-afd1-4e7a4394a264@github.com>
Message-ID: <jDbYTS6DczPexPxGA8p1KgVZCimj-pUm8m3eFsZc338=.f141daa6-bd7a-494f-98f1-146093797603@github.com>

On Mon, 15 Jan 2024 16:23:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing comma in TestScope.java
>
> test/jdk/java/foreign/TestScope.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2024 Oracle and/or its affiliates. All rights reserved.
> 
> Can you hold off on this until TestScope.java's copyright header is fixed in main line.

This has been fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk22/pull/77#discussion_r1453122625

From chegar at openjdk.org  Tue Jan 16 09:11:01 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Tue, 16 Jan 2024 09:11:01 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v7]
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <_uYt4yx2EmiBRwC_aItraPTBrieQCbCPXBihcenA_kk=.755f283c-b9bf-4ad1-9782-222424373e8d@github.com>

> Update LinkedTransferQueue add and put methods to not call overridable offer.

Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into ltq_bug
 - Merge branch 'master' into ltq_bug
 - order of tags
 - Merge branch 'master' into ltq_bug
 - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - timed offer
 - add test
 - Update LinkedTransferQueue add and put methods to not call overridable offer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17393/files
  - new: https://git.openjdk.org/jdk/pull/17393/files/3aa026fa..ddaab989

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17393&range=05-06

  Stats: 125 lines in 18 files changed: 86 ins; 30 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17393/head:pull/17393

PR: https://git.openjdk.org/jdk/pull/17393

From pminborg at openjdk.org  Tue Jan 16 09:12:21 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Jan 2024 09:12:21 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v2]
In-Reply-To: <MquxdkvcIBJlp-pVsWFUBmtml73w5S3SREEyRan45KA=.c6e91302-a946-4f26-ac02-211f7620c7f8@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <ZTu8tRFAFOnSQMcJ73QHSbWT02D-b0ynG2-hBDYT9m8=.db114fd6-1903-4493-976e-1ee940de55ab@github.com>
 <MquxdkvcIBJlp-pVsWFUBmtml73w5S3SREEyRan45KA=.c6e91302-a946-4f26-ac02-211f7620c7f8@github.com>
Message-ID: <SRNbpJUz7ZBtRkWq627Fsr2A287Zvu2WwsITJTco-9M=.263e8ccb-4707-4777-8d8a-81a3bf74a529@github.com>

On Mon, 15 Jan 2024 17:10:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework PathElement:toString
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 958:
> 
>> 956:             return new LayoutPath.PathElementImpl(PathKind.DEREF_ELEMENT,
>> 957:                     LayoutPath::derefElement,
>> 958:                     "*");
> 
> It seems that this would result in paths like `a.b*` rather than the `*a.b`, which is correct C syntax.

Correct. Additional logic is needed to form a correct C syntax. It would be possible to provide a method that does this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17417#discussion_r1453127266

From alanb at openjdk.org  Tue Jan 16 09:39:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 09:39:19 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <LWiyL3eeLdiiLvoHRwisxmcEmE4r3i1g0TE1bUFGL0c=.5b11d56b-0805-4067-8fc0-880ef86a5db8@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1822902993

From jbhateja at openjdk.org  Tue Jan 16 10:26:28 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 10:26:28 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <T7nSIu84cN723Gaf9cBxqHwVhneW2PtGOEGQcMbyD3I=.a9122e47-fdf7-45bf-9ca5-ca9b08718e10@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/share/opto/library_call.cpp line 1228:

> 1226:     result = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
> 1227:   } else {
> 1228:     result = make_indexOf_node(src_start, src_count, tgt_start, tgt_count,

Existing routines emits IR to handle following special cases.

tgt_cnt > src_cnt return -1
tgt_cnt == 0 return 0.

Should we not be preserving those check before calling stub ?

As of now these checks are part of stub and doing them in JIT code will save call overhead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453223658

From aturbanov at openjdk.org  Tue Jan 16 10:27:37 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 16 Jan 2024 10:27:37 GMT
Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized'
 unnecessarily
Message-ID: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>

8291027: Some of TimeZone methods marked 'synchronized' unnecessarily

-------------

Commit messages:
 - 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily

Changes: https://git.openjdk.org/jdk/pull/17441/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17441&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291027
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17441.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17441/head:pull/17441

PR: https://git.openjdk.org/jdk/pull/17441

From prappo at openjdk.org  Tue Jan 16 10:43:19 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 16 Jan 2024 10:43:19 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
In-Reply-To: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
References: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
Message-ID: <DzQQXEzjcNRNTDtX3pQQluESfhDUXzMCpsWASwd1bDU=.44406967-b6c6-46c8-9330-344012666640@github.com>

On Tue, 16 Jan 2024 07:40:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.

src/java.base/share/classes/java/util/Map.java line 820:

> 818:      * @param key key with which the specified value is to be associated
> 819:      * @param value value to be associated with the specified key
> 820:      * @return {@code null} if the specified key was considered absent, else returns

"Considered" feels out of place. No other method in Map uses it. Try to rephrase that sentence or, if it helps, the complete `@return` tag. (@stuart-marks might have more substantial feedback.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17438#discussion_r1453244818

From redestad at openjdk.org  Tue Jan 16 10:59:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 16 Jan 2024 10:59:57 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
Message-ID: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>

There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.

This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

-------------

Commit messages:
 - 8323794: Remove unused jimage compressor plugin configuration

Changes: https://git.openjdk.org/jdk/pull/17443/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323794
  Stats: 67 lines in 12 files changed: 2 ins; 39 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17443/head:pull/17443

PR: https://git.openjdk.org/jdk/pull/17443

From jhendrikx at openjdk.org  Tue Jan 16 11:06:20 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Jan 2024 11:06:20 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
In-Reply-To: <DzQQXEzjcNRNTDtX3pQQluESfhDUXzMCpsWASwd1bDU=.44406967-b6c6-46c8-9330-344012666640@github.com>
References: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
 <DzQQXEzjcNRNTDtX3pQQluESfhDUXzMCpsWASwd1bDU=.44406967-b6c6-46c8-9330-344012666640@github.com>
Message-ID: <OYxuAmHURjuiGmhHcemOcg9RXnT7xB2tXmdOfhfJQK0=.28f37168-daf7-49c4-a2f0-b84105cd4f71@github.com>

On Tue, 16 Jan 2024 10:41:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> src/java.base/share/classes/java/util/Map.java line 820:
> 
>> 818:      * @param key key with which the specified value is to be associated
>> 819:      * @param value value to be associated with the specified key
>> 820:      * @return {@code null} if the specified key was considered absent, else returns
> 
> "Considered" feels out of place. No other method in Map uses it. Try to rephrase that sentence or, if it helps, the complete `@return` tag. (@stuart-marks might have more substantial feedback.)

Yeah, I wasn't sure about that, I can make it more specific, I used `considered` here because both unmapped and key maps to `null` is considered to be absent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17438#discussion_r1453271276

From aturbanov at openjdk.org  Tue Jan 16 11:16:21 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 16 Jan 2024 11:16:21 GMT
Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized'
 unnecessarily
In-Reply-To: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
References: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
Message-ID: <oeypt73pZ3oIF1BQU-Nnn8IO5Jb5kvZ4w5ngam36TBs=.a7141969-655c-41b4-8dca-94cca69d6662@github.com>

On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily

src/java.base/share/classes/java/util/TimeZone.java line 629:

> 627:      */
> 628:     public static String[] getAvailableIDs(int rawOffset) {
> 629:         return ZoneInfo.getAvailableIDs(rawOffset);

BTW can we call `ZoneInfoFile.getZoneIds` here directly? 
`ZoneInfo.getAvailableIDs` bridge seems unnecessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17441#discussion_r1453280995

From jbhateja at openjdk.org  Tue Jan 16 11:30:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 11:30:26 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <zPOcH3xgYDuuksK6nwszHDxHILiPep-GvMkZ7oKWt38=.40e1520e-76ac-4bf0-84b1-f767d24dffe9@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1528:

> 1526: #endif
> 1527: 
> 1528:     __ subptr(rsp, 0xf0);

Can we spill them into XXMs, to save costly stack operations.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1544:

> 1542:     // if (k == 0) {
> 1543:     //   return 0;
> 1544:     // }

Kindly use meaningful variable and label names. It will ease the review process and maintenance.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1545:

> 1543:     //   return 0;
> 1544:     // }
> 1545:     __ movq(r12, rcx);

Check for K == 0 should use rsi.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1551:

> 1549:     __ movq(r15, rsi);
> 1550:     __ movq(r11, rdi);
> 1551:     __ cmpq(rsi, 0x20);

All comparisons are with 32 bit int value , cmpq -> cmpl,  may save emitting REX encoding prefix (no need for setting REX.W).

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1552:

> 1550:     __ movq(r11, rdi);
> 1551:     __ cmpq(rsi, 0x20);
> 1552:     __ jb(L_small_string);

All the comparisons against needled / haystack lengths are signed integer comparisons, so jb should be replaced by jl

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453226797
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453227987
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453245805
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453250207
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453294109

From jbhateja at openjdk.org  Tue Jan 16 12:04:21 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 12:04:21 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <VUYlxznGBqQQI_KLmrnBHTePD7kuY7KGQtaT71UGP00=.c906736a-35ed-4125-be93-f54be0be9cd3@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

label /add hotspot-compiler-dev

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1893605792

From jbhateja at openjdk.org  Tue Jan 16 12:12:34 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 12:12:34 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <nt4SRGQg7xCi2b0B0Beeobfce594QZxkYBUV8vJ4pcM=.9183d4a7-485f-40c6-ae1d-51977e629abb@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 197:

> 195:     __ bind(L_small_string);
> 196:     __ cmpq(r15, 0x20);
> 197:     __ ja(L_small_string2);

ja should replaced by jg.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1526:

> 1524:     __ movq(rdx, r8);
> 1525:     __ movq(rcx, r9);
> 1526: #endif

Can we spill them into XXMs, to save costly stack operations.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1545:

> 1543:     //   return 0;
> 1544:     // }
> 1545:     __ movq(r12, rcx);

Kindly use meaningful variable and label names. It will ease the review process and maintenance.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1551:

> 1549:     __ movq(r15, rsi);
> 1550:     __ movq(r11, rdi);
> 1551:     __ cmpq(rsi, 0x20);

All comparisons are with 32 bit int value , cmpq -> cmpl, may save emitting REX encoding prefix (no need for setting REX.W).

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1552:

> 1550:     __ movq(r11, rdi);
> 1551:     __ cmpq(rsi, 0x20);
> 1552:     __ jb(L_small_string);

All the comparisons against needle length are signed integer comparisons, so jb should be replaced by jl

src/hotspot/share/opto/library_call.cpp line 1206:

> 1204: 
> 1205:   Node* result = nullptr;
> 1206:   bool do_intrinsic =

Name change suggestion: do_intrinsic -> call_opt_stub

src/hotspot/share/opto/library_call.cpp line 1229:

> 1227:   } else {
> 1228:     result = make_indexOf_node(src_start, src_count, tgt_start, tgt_count,
> 1229:                                result_rgn, result_phi, ae);

Existing routines emits IR to handle following special cases.

tgt_cnt > src_cnt return -1
tgt_cnt == 0 return 0.

Should we not be preserving those check before calling stub ?

As of now these checks are part of stub and doing them in JIT code will save call overhead.

src/hotspot/share/opto/runtime.cpp line 1347:

> 1345:   fields[argp++] = TypeInt::INT;        // needle length
> 1346:   fields[argp++] = TypePtr::NOTNULL;    // haystack array
> 1347:   fields[argp++] = TypeInt::INT;        // haystack length

Do we need to swap the comments? first two arguments corresponds to value (haystack) as per java side intrinsic signature.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L348

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453304911
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453332647
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453333045
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453333555
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453333878
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453338427
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453338718
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453329079

From chegar at openjdk.org  Tue Jan 16 12:16:32 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Tue, 16 Jan 2024 12:16:32 GMT
Subject: Integrated: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
Message-ID: <MEgAwzdFlc44ox8wq8Ml4tcgC6SvAEI0QyHO0iclL3c=.ff0fa8b6-992f-4d73-95f8-2c1353ccbfc1@github.com>

On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Update LinkedTransferQueue add and put methods to not call overridable offer.

This pull request has now been integrated.

Changeset: ee4d9aa4
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7
Stats:     75 lines in 2 files changed: 72 ins; 0 del; 3 mod

8323659: LinkedTransferQueue add and put methods call overridable offer

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17393

From chegar at openjdk.org  Tue Jan 16 12:29:36 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Tue, 16 Jan 2024 12:29:36 GMT
Subject: [jdk22] RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
Message-ID: <6-eQOqLF0g-qsPb7gisku6DUuhMuJ_AYva4CUXedlYo=.f1a6d923-92f7-4377-91f4-3e558c0de778@github.com>

Hi all,

This pull request contains a backport of commit [ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Chris Hegarty on 16 Jan 2024 and was reviewed by Alan Bateman.

Thanks!

-------------

Commit messages:
 - Backport ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7

Changes: https://git.openjdk.org/jdk22/pull/80/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323659
  Stats: 75 lines in 2 files changed: 72 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk22/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/80/head:pull/80

PR: https://git.openjdk.org/jdk22/pull/80

From alanb at openjdk.org  Tue Jan 16 12:32:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 12:32:24 GMT
Subject: [jdk22] RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer
In-Reply-To: <6-eQOqLF0g-qsPb7gisku6DUuhMuJ_AYva4CUXedlYo=.f1a6d923-92f7-4377-91f4-3e558c0de778@github.com>
References: <6-eQOqLF0g-qsPb7gisku6DUuhMuJ_AYva4CUXedlYo=.f1a6d923-92f7-4377-91f4-3e558c0de778@github.com>
Message-ID: <J6KJrEr0SIeoiKJ8Lp8NUr9RfYqD4gSw3MbMvIYP10U=.5046a931-c27f-4a58-b5ef-1c131dc25530@github.com>

On Tue, 16 Jan 2024 12:23:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 16 Jan 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/80#pullrequestreview-1823225500

From jbhateja at openjdk.org  Tue Jan 16 13:29:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 13:29:24 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <0XxCusssrDiiKzXBfdsY1XHkv9T6mJwJe7dwFz5Uy-I=.3325e496-5bf1-4a79-8969-e28e018b77db@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 417:

> 415:     __ cmpl(Address(rbx, r15, Address::times_1, -0x14), rax);
> 416:     __ jne(L_top_loop_1);
> 417:     __ jmp(L_0x406019);

For cases which are multiple of 4 bytes we can use VMASKMOVPS (conditional moves) and VPTEST.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453425855

From liach at openjdk.org  Tue Jan 16 13:30:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Jan 2024 13:30:27 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
In-Reply-To: <OYxuAmHURjuiGmhHcemOcg9RXnT7xB2tXmdOfhfJQK0=.28f37168-daf7-49c4-a2f0-b84105cd4f71@github.com>
References: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
 <DzQQXEzjcNRNTDtX3pQQluESfhDUXzMCpsWASwd1bDU=.44406967-b6c6-46c8-9330-344012666640@github.com>
 <OYxuAmHURjuiGmhHcemOcg9RXnT7xB2tXmdOfhfJQK0=.28f37168-daf7-49c4-a2f0-b84105cd4f71@github.com>
Message-ID: <pFWjSHLea-Kz6wXEk7UB8avzQ5wmMHawTENFSZ1ajNU=.151f497c-5945-42f1-8fd1-f26d50369125@github.com>

On Tue, 16 Jan 2024 11:03:28 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Map.java line 820:
>> 
>>> 818:      * @param key key with which the specified value is to be associated
>>> 819:      * @param value value to be associated with the specified key
>>> 820:      * @return {@code null} if the specified key was considered absent, else returns
>> 
>> "Considered" feels out of place. No other method in Map uses it. Try to rephrase that sentence or, if it helps, the complete `@return` tag. (@stuart-marks might have more substantial feedback.)
>
> Yeah, I wasn't sure about that, I can make it more specific, I used `considered` here because both unmapped keys and keys mapped to `null` are considered to be absent.

I think `absent or {@code null}` is no less concise yet it is way more accurate than `considered absent`. So something like `@return {@code null} if the mapping for the specified key is absent or has a {@code null} value`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17438#discussion_r1453427452

From jbhateja at openjdk.org  Tue Jan 16 13:32:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Jan 2024 13:32:25 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <dqCXTvmNMBiCnzRRs9ocZMxDKo7EWfdkrieG0bLbXMs=.2edcbc58-7534-4784-a832-0eb3ef39e9fa@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 470:

> 468:     __ jne(L_top_loop_1);
> 469:     __ jmp(L_0x406019);
> 470: 

For 16 bytes  we can directly use [V]PTEST instruction to save multiple loads and compares.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1453429803

From jpai at openjdk.org  Tue Jan 16 13:45:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 13:45:27 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
Message-ID: <bZEgUS1qIM1_x-yQiGU1Ll2tlxAO-Y7oXJrFVD7_AqA=.7b431c1e-46c9-4661-babd-ca5872d8fd30@github.com>

On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Remove trailing whitespace

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:

> 532: 
> 533:         long csize = get32(tmpbuf, LOCSIZ);
> 534:         long size = get32(tmpbuf, LOCLEN);

Hello Eirik, I suspect this part of the change has an issue. Before reading the `tmpbuf` for compressed and uncompressed sizes, there will be 32 bits of CRC, which should be read first. This now skips those 32 CRC bits and reads them (in the else block) after reading these sizes and that can cause incorrect LOC data.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453442814

From jpai at openjdk.org  Tue Jan 16 13:45:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 13:45:28 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <bZEgUS1qIM1_x-yQiGU1Ll2tlxAO-Y7oXJrFVD7_AqA=.7b431c1e-46c9-4661-babd-ca5872d8fd30@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <bZEgUS1qIM1_x-yQiGU1Ll2tlxAO-Y7oXJrFVD7_AqA=.7b431c1e-46c9-4661-babd-ca5872d8fd30@github.com>
Message-ID: <A_AljENFTFOLEQjmv2yJ_rZZRpbMhfyB772775XrP1A=.66e73b70-9495-4f2d-ae71-399f60ce7df1@github.com>

On Tue, 16 Jan 2024 13:40:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:
> 
>> 532: 
>> 533:         long csize = get32(tmpbuf, LOCSIZ);
>> 534:         long size = get32(tmpbuf, LOCLEN);
> 
> Hello Eirik, I suspect this part of the change has an issue. Before reading the `tmpbuf` for compressed and uncompressed sizes, there will be 32 bits of CRC, which should be read first. This now skips those 32 CRC bits and reads them (in the else block) after reading these sizes and that can cause incorrect LOC data.

The Github actions job which runs tier1 is all successful with this proposed change. So I'm a bit surprised that the tests didn't catch any issues, which makes me wonder if we have enough test coverage that covers this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453445673

From jpai at openjdk.org  Tue Jan 16 13:56:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 13:56:30 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
Message-ID: <33U0s06xG2FNIDYsaZ0oPOnF1uoZUw4cwZgpY1AYrhI=.4d6e8dc7-8cba-41f0-bd8b-252d64e810fb@github.com>

On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Remove trailing whitespace

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 664:

> 662: 
> 663:         // The LOC's 'compressed size' and 'uncompressed size' must both be marked for Zip64
> 664:         if (csize != ZIP64_MAGICVAL || size != ZIP64_MAGICVAL) {

The spec for this says different. It says:

>
> 4.4.4 general purpose bit flag:
> ...
>    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.  

So it expects the value zero for the compressed/uncompressed sizes in the LOC when the data descriptor bit is set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453460177

From eirbjo at openjdk.org  Tue Jan 16 14:32:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 16 Jan 2024 14:32:51 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v13]
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: <BrShtYX443Li3d-w5xCkNF3oym-qN0ADg5QBP5pIBaw=.5319e3a4-0a0f-4b57-a681-e180de81e368@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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra whitespace
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/91fbcce5..1aedf3e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=11-12

  Stats: 1 line in 1 file changed: 0 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 jpai at openjdk.org  Tue Jan 16 14:32:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 14:32:53 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
Message-ID: <6QTr4-geN0qoprsiXi0Z3hbtZkn1Q36YjB4EGYXIoxk=.7779f249-f1b5-4da1-ab94-1e35b316f2aa@github.com>

On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Remove trailing whitespace

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 706:

> 704:      * @return true if the extra field is a Zip64 extra field compatible with data descriptors
> 705:      */
> 706:     private static boolean isZip64DataDescriptorField(int headerId, byte[] extra, int blockStart, int blockSize) {

I understand the goals of this method - what it's trying to do is, assure the caller that the extra field/block actually is a zip64 extra block. That assurance is then used to access the data descriptor content as 8 byte fields. 
However, I think in this proposed implementation of this method we are perhaps doing a bit too much. Specifically, I don't think we should check what values have been stamped for "Original size" and "Compressed size" fields of this zip64 block. I think, those values (presence or absence) shouldn't play a role in deciding whether we have to read a data descriptor size fields as 8 bytes. Doing these checks for these zip64 original/compressed size fields, I think will open up more permutations about which zip entries get processed as 8 byte data descriptors.

Given the context in which this method is used, I think the only checks that we should do in this method is to verify that the header id is `ZIP64_EXTID`. 
Perhaps then this `isZip64DataDescriptorField(...)` won't be needed and we can just inline that `headerid == ZIP64_EXTID` check inline in the implementation of `expect64BitDataDescriptor(...)` method

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453508949

From jpai at openjdk.org  Tue Jan 16 14:37:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 14:37:31 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v13]
In-Reply-To: <BrShtYX443Li3d-w5xCkNF3oym-qN0ADg5QBP5pIBaw=.5319e3a4-0a0f-4b57-a681-e180de81e368@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <BrShtYX443Li3d-w5xCkNF3oym-qN0ADg5QBP5pIBaw=.5319e3a4-0a0f-4b57-a681-e180de81e368@github.com>
Message-ID: <gEBFq18-AOLbNNmK3EPdbBlCu4ig_mzL4M-85w_k40c=.d77a61c4-d42b-4dc3-a6aa-d2cba1e42634@github.com>

On Tue, 16 Jan 2024 14:32:51 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra whitespace
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

On a general note - thank you for updating this PR from the previous proposed approach. The current proposed approach of solely relying on the data that comes from within the stream to decide whether or not to use 8 bytes for a data descriptor compressed/uncompressed fields, looks right to me. That prevents issues related to basing this decision on some application controlled/manipulated data which may not match the stream content.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1893873146

From eirbjo at openjdk.org  Tue Jan 16 14:37:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 16 Jan 2024 14:37:33 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <A_AljENFTFOLEQjmv2yJ_rZZRpbMhfyB772775XrP1A=.66e73b70-9495-4f2d-ae71-399f60ce7df1@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <bZEgUS1qIM1_x-yQiGU1Ll2tlxAO-Y7oXJrFVD7_AqA=.7b431c1e-46c9-4661-babd-ca5872d8fd30@github.com>
 <A_AljENFTFOLEQjmv2yJ_rZZRpbMhfyB772775XrP1A=.66e73b70-9495-4f2d-ae71-399f60ce7df1@github.com>
Message-ID: <8Bly6Z-xtdaeNSQXFwh76SKyXh-vzPW7nUjYGfu2Kdg=.ab38ccce-f884-4cf4-b039-48ec5b34d278@github.com>

On Tue, 16 Jan 2024 13:42:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:
>> 
>>> 532: 
>>> 533:         long csize = get32(tmpbuf, LOCSIZ);
>>> 534:         long size = get32(tmpbuf, LOCLEN);
>> 
>> Hello Eirik, I suspect this part of the change has an issue. Before reading the `tmpbuf` for compressed and uncompressed sizes, there will be 32 bits of CRC, which should be read first. This now skips those 32 CRC bits and reads them (in the else block) after reading these sizes and that can cause incorrect LOC data.
>
> The Github actions job which runs tier1 is all successful with this proposed change. So I'm a bit surprised that the tests didn't catch any issues, which makes me wonder if we have enough test coverage that covers this change.

> Hello Eirik, I suspect this part of the change has an issue. Before reading the `tmpbuf` for compressed and uncompressed sizes, there will be 32 bits of CRC, which should be read first. This now skips those 32 CRC bits and reads them (in the else block) after reading these sizes and that can cause incorrect LOC data.

How does the order of the reads from the byte array matter? Outside cache efficiency I would presume they could be read in any order?

(These reads are from a temp buffer, not the stream)

Could you elaborate? I'm not sure I'm following :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453516319

From jpai at openjdk.org  Tue Jan 16 14:43:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 14:43:28 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <8Bly6Z-xtdaeNSQXFwh76SKyXh-vzPW7nUjYGfu2Kdg=.ab38ccce-f884-4cf4-b039-48ec5b34d278@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <bZEgUS1qIM1_x-yQiGU1Ll2tlxAO-Y7oXJrFVD7_AqA=.7b431c1e-46c9-4661-babd-ca5872d8fd30@github.com>
 <A_AljENFTFOLEQjmv2yJ_rZZRpbMhfyB772775XrP1A=.66e73b70-9495-4f2d-ae71-399f60ce7df1@github.com>
 <8Bly6Z-xtdaeNSQXFwh76SKyXh-vzPW7nUjYGfu2Kdg=.ab38ccce-f884-4cf4-b039-48ec5b34d278@github.com>
Message-ID: <y0sFPRdIRDtIq6QkxkXjV5zpjZBeu9qc3eRxLm1q6eU=.31c074bb-0135-463c-839d-683721912c61@github.com>

On Tue, 16 Jan 2024 14:34:29 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>(These reads are from a temp buffer, not the stream)

Ah! you are right indeed. I didn't correctly read that part of that code. It's reading from a temp buffer which has been fully initialized with a LOC and these reads happens with specific offsets within that buffer. So yes, you are correct that the order won't matter here. Thank you for that detail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453524828

From eirbjo at openjdk.org  Tue Jan 16 14:43:32 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 16 Jan 2024 14:43:32 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <33U0s06xG2FNIDYsaZ0oPOnF1uoZUw4cwZgpY1AYrhI=.4d6e8dc7-8cba-41f0-bd8b-252d64e810fb@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <33U0s06xG2FNIDYsaZ0oPOnF1uoZUw4cwZgpY1AYrhI=.4d6e8dc7-8cba-41f0-bd8b-252d64e810fb@github.com>
Message-ID: <guU5N9ppbMKZvGppayMCoUAAlxGiSt7cTs71d9I40HE=.43440217-73fc-431f-9da9-8268d15ad805@github.com>

On Tue, 16 Jan 2024 13:54:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 664:
> 
>> 662: 
>> 663:         // The LOC's 'compressed size' and 'uncompressed size' must both be marked for Zip64
>> 664:         if (csize != ZIP64_MAGICVAL || size != ZIP64_MAGICVAL) {
> 
> The spec for this says different. It says:
> 
>>
>> 4.4.4 general purpose bit flag:
>> ...
>>    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.  
> 
> So it expects the value zero for the compressed/uncompressed sizes in the LOC when the data descriptor bit is set.

The spec isn't terribly helpful in spelling out what should happen in the case where an entry combines the uses of  data descriptors (mandating that CRC, size and compressed size must be zero) with Zip64 (mandating that size and compressed size must be 0xFFFFFFFF)

My interpretation (based in the InfoZIP implementation) is that in such cases, CRC should be zero, while size and compressed size should be 0xFFFFFFFF, with their counterparts in the Zip64 extra field should set to zero.

Does this make sense?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453526069

From eirbjo at openjdk.org  Tue Jan 16 14:58:57 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 16 Jan 2024 14:58:57 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v14]
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: <_jCBug-AoTSyFNEG0mpdO24dI9OHExnXPVGv6XVaCms=.0fa11b75-1662-42d1-92b3-35cb952d3a3e@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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra whitespace
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/1aedf3e5..cfd53910

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=12-13

  Stats: 1 line in 1 file changed: 0 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 jpai at openjdk.org  Tue Jan 16 14:58:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 14:58:58 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <guU5N9ppbMKZvGppayMCoUAAlxGiSt7cTs71d9I40HE=.43440217-73fc-431f-9da9-8268d15ad805@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <33U0s06xG2FNIDYsaZ0oPOnF1uoZUw4cwZgpY1AYrhI=.4d6e8dc7-8cba-41f0-bd8b-252d64e810fb@github.com>
 <guU5N9ppbMKZvGppayMCoUAAlxGiSt7cTs71d9I40HE=.43440217-73fc-431f-9da9-8268d15ad805@github.com>
Message-ID: <ga90hOxKqdOMq97zdDfeobco2FXuQOjF-Pdfn4jhgVU=.28131301-7ca6-48b7-8e7f-444fc3994d87@github.com>

On Tue, 16 Jan 2024 14:41:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> The spec isn't terribly helpful in spelling out what should happen in the case where an entry combines the uses of data descriptors (mandating that CRC, size and compressed size must be zero) with Zip64 (mandating that size and compressed size must be 0xFFFFFFFF)

I see what you mean. However, given that the data descriptor general bit field is set to indicate that the data descriptor should be honoured, plus the spec stating that the original/compressed sizes in the zip64 extra block aren't mandatory, I think not relying on the zip64 extra block for parsing decisions about a data descriptor content might be better. I think the only role that a zip64 block should play when we are deciding how to parse a data descriptor is whether or not the entry has zip64 extra field set (the header id value of the extra field). Does that sound reasonable?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453546995

From jpai at openjdk.org  Tue Jan 16 15:07:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 15:07:20 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v4]
In-Reply-To: <Airpkbb74hed7sPRNLTr7uVs5Qon5SNKCfDjMYyGJHY=.d2d39b82-4ddf-4511-898c-de0c48318277@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <Airpkbb74hed7sPRNLTr7uVs5Qon5SNKCfDjMYyGJHY=.d2d39b82-4ddf-4511-898c-de0c48318277@github.com>
Message-ID: <qfvbXeJnKzdX2Ga08Sxa3wJqMlmG-SnFz2gi4oiaN7M=.dbfa7972-d019-4ad7-89da-1e9ca0d46cd1@github.com>

On Mon, 15 Jan 2024 10:26:53 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once.
>> 
>> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
>> 
>> This fix is to move the closing of the wrapped stream inside the finally block.
>> 
>> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?)
>> 
>> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
>> 
>> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
>> 
>> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/util/zip/ZipOutputStream/CloseWrappedStream.java
>   
>   Remove extra whitespace
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

The source changes as well as the test looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17209#pullrequestreview-1823702967

From jpai at openjdk.org  Tue Jan 16 15:19:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Jan 2024 15:19:27 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v6]
In-Reply-To: <3t7-samFVSG-gKrTp9-slrWbUqk0zCO_JzNJtlpPKXE=.5dbb8f64-f1b2-49d6-8f18-8f1451e77006@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <3t7-samFVSG-gKrTp9-slrWbUqk0zCO_JzNJtlpPKXE=.5dbb8f64-f1b2-49d6-8f18-8f1451e77006@github.com>
Message-ID: <s_E-9uqQlS4Ri6kqN6s7cQqIqnF7MDQa6fcB5Ya64dA=.d4ec91a5-5e70-4f2a-9567-9c819012f2a3@github.com>

On Mon, 20 Nov 2023 16:24:31 GMT, Glavo <duke at openjdk.org> wrote:

>> Using `ByteArrayLittleEndian` is simpler and faster.
>> 
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>> 
>> 
>>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
>> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
>> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
>> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
>> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - use ByteArrayLittleEndian in ZipUtils

Hello Glavo, I see that you are interested in pursuing this change further. Would you mind getting the latest micro benchmark numbers which this proposed change? I see that your PR description has a run from some time back, getting a latest one would be useful.

Additionally, I see that https://github.com/openjdk/jdk/pull/14636 where you had proposed a test case for the `ByteArrayLittleEndian` class (in addition to other things) got closed without being integrated. Would you mind adding a new test case for that class as part of this current PR since you have a few more new methods being added to that class?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1893953682

From duke at openjdk.org  Tue Jan 16 16:02:25 2024
From: duke at openjdk.org (Glavo)
Date: Tue, 16 Jan 2024 16:02:25 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v6]
In-Reply-To: <3t7-samFVSG-gKrTp9-slrWbUqk0zCO_JzNJtlpPKXE=.5dbb8f64-f1b2-49d6-8f18-8f1451e77006@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <3t7-samFVSG-gKrTp9-slrWbUqk0zCO_JzNJtlpPKXE=.5dbb8f64-f1b2-49d6-8f18-8f1451e77006@github.com>
Message-ID: <NUaBwaWkTrqH_u6MXdPsrguS4lRxUwegKlng1V69rNE=.5e82b089-33c7-4024-a2b1-dc7ba7358c72@github.com>

On Mon, 20 Nov 2023 16:24:31 GMT, Glavo <duke at openjdk.org> wrote:

>> Using `ByteArrayLittleEndian` is simpler and faster.
>> 
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>> 
>> 
>>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
>> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
>> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
>> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
>> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - use ByteArrayLittleEndian in ZipUtils

> Hello Glavo, I see that you are interested in pursuing this change further. Would you mind getting the latest micro benchmark numbers which this proposed change? I see that your PR description has a run from some time back, getting a latest one would be useful.
> 
> Additionally, I see that #14636 where you had proposed a test case for the `ByteArrayLittleEndian` class (in addition to other things) got closed without being integrated. Would you mind adding a new test case for that class as part of this current PR since you have a few more new methods being added to that class?

I've moved those changes into this PR and am running tests. I'll push these changes once the tests are finished running.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1894037304

From jlaskey at openjdk.org  Tue Jan 16 16:06:21 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 16 Jan 2024 16:06:21 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
In-Reply-To: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
Message-ID: <U7faxOGwFLyvuJnZ15bhEh1yGBoTMrXQJ61Vi5YDeOo=.20f28bda-abb3-4939-acdd-dc91bde88915@github.com>

On Tue, 16 Jan 2024 10:55:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
> 
> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

Changes requested by jlaskey (Reviewer).

src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java line 104:

> 102:         ByteBuffer buffer = ByteBuffer.wrap(resource, 0, SIZE);
> 103:         buffer.order(order);
> 104:         int magic = buffer.getInt(0);

Named constant for offsets?

src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java line 108:

> 106:             return null;
> 107:         }
> 108:         long size = buffer.getLong(4);

Named constant for offsets?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17443#pullrequestreview-1823928256
PR Review Comment: https://git.openjdk.org/jdk/pull/17443#discussion_r1453640996
PR Review Comment: https://git.openjdk.org/jdk/pull/17443#discussion_r1453641242

From duke at openjdk.org  Tue Jan 16 16:38:34 2024
From: duke at openjdk.org (Glavo)
Date: Tue, 16 Jan 2024 16:38:34 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v7]
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <FS9pMXFiu6nqMi9yMBOVH241oOyBQIUJVcG1pCULPTw=.33fb1a8a-8102-459a-b08b-9cfc8bd13185@github.com>

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Add tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14632/files
  - new: https://git.openjdk.org/jdk/pull/14632/files/72175ea1..a9b6b78e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=05-06

  Stats: 440 lines in 4 files changed: 339 ins; 19 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/14632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14632/head:pull/14632

PR: https://git.openjdk.org/jdk/pull/14632

From duke at openjdk.org  Tue Jan 16 17:18:24 2024
From: duke at openjdk.org (Glavo)
Date: Tue, 16 Jan 2024 17:18:24 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v7]
In-Reply-To: <FS9pMXFiu6nqMi9yMBOVH241oOyBQIUJVcG1pCULPTw=.33fb1a8a-8102-459a-b08b-9cfc8bd13185@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <FS9pMXFiu6nqMi9yMBOVH241oOyBQIUJVcG1pCULPTw=.33fb1a8a-8102-459a-b08b-9cfc8bd13185@github.com>
Message-ID: <2SoTr0Gn9b5VNIGzM-RMaJjc2NxotpCoTCgM27k8VNU=.9179c8e6-39da-4b07-a9be-449df029c0b5@github.com>

On Tue, 16 Jan 2024 16:38:34 GMT, Glavo <duke at openjdk.org> wrote:

>> Using `ByteArrayLittleEndian` is simpler and faster.
>> 
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>> 
>> 
>>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
>> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
>> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
>> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
>> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add tests

I ran the tier1 tests with no failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1894174227

From mcimadamore at openjdk.org  Tue Jan 16 17:25:27 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 Jan 2024 17:25:27 GMT
Subject: [jdk22] RFR: 8323159: Consider adding some text re. memory zeroing
 in Arena::allocate [v2]
In-Reply-To: <UB4Cvt1Tuiv2_sZAdkNCaS48fuozwIzxmFQqJFk_faI=.f01497f2-e38b-4ea9-9785-783b53005b64@github.com>
References: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
 <UB4Cvt1Tuiv2_sZAdkNCaS48fuozwIzxmFQqJFk_faI=.f01497f2-e38b-4ea9-9785-783b53005b64@github.com>
Message-ID: <7xyvJ_lDhbvv2mx4hxR2wYFUhB0Ol2AXnqNGPQI1V4U=.6d9cd289-084d-4b09-8c94-17b64730f9ec@github.com>

On Tue, 16 Jan 2024 08:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> 8323159: Consider adding some text re. memory zeroing in Arena::allocate
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing comma in TestScope.java

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/77#pullrequestreview-1824307173

From acobbs at openjdk.org  Tue Jan 16 17:34:07 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Jan 2024 17:34:07 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v5]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <d84pA2eQE0PA2EuaBUHBEeGVk8flPnGR20HmsWQvRhs=.cba21703-1aa7-42e5-bd40-6f48892a1dd2@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK-7036144
 - Address third round of review comments.
 - Address second round of review comments.
 - Address review comments.
 - Fix bug in GZIPInputStream when underlying available() returns short.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/cf457eff..4f1a0459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=03-04

  Stats: 35310 lines in 1143 files changed: 22955 ins; 7236 del; 5119 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 alanb at openjdk.org  Tue Jan 16 17:37:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 17:37:23 GMT
Subject: [jdk22] RFR: 8323159: Consider adding some text re. memory zeroing
 in Arena::allocate [v2]
In-Reply-To: <UB4Cvt1Tuiv2_sZAdkNCaS48fuozwIzxmFQqJFk_faI=.f01497f2-e38b-4ea9-9785-783b53005b64@github.com>
References: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
 <UB4Cvt1Tuiv2_sZAdkNCaS48fuozwIzxmFQqJFk_faI=.f01497f2-e38b-4ea9-9785-783b53005b64@github.com>
Message-ID: <WmPrGxwTrZTabNUuKFSh-Kxk9q-4l4tYVCcWBgIt6YE=.cb597503-94b3-4b96-9c3c-77d91e1407a7@github.com>

On Tue, 16 Jan 2024 08:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> 8323159: Consider adding some text re. memory zeroing in Arena::allocate
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing comma in TestScope.java

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/77#pullrequestreview-1824361691

From henryjen at openjdk.org  Tue Jan 16 17:46:21 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 16 Jan 2024 17:46:21 GMT
Subject: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1
Message-ID: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>

CPU24_01 fixes.

-------------

Commit messages:
 - 8317547: Enhance TLS connection support
 - 8314307: Improve loop handling
 - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
 - 8314468: Improve Compiler loops
 - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
 - 8314295: Enhance verification of verifier
 - 8308204: Enhanced certificate processing

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/17448/files
  Stats: 736 lines in 16 files changed: 476 ins; 65 del; 195 mod
  Patch: https://git.openjdk.org/jdk/pull/17448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17448/head:pull/17448

PR: https://git.openjdk.org/jdk/pull/17448

From henryjen at openjdk.org  Tue Jan 16 18:02:26 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 16 Jan 2024 18:02:26 GMT
Subject: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b
Message-ID: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>

CPU24_01 fixes.

-------------

Commit messages:
 - 8317547: Enhance TLS connection support
 - 8314307: Improve loop handling
 - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
 - 8314468: Improve Compiler loops
 - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
 - 8314295: Enhance verification of verifier
 - 8308204: Enhanced certificate processing

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk22/pull/83/files
  Stats: 736 lines in 16 files changed: 476 ins; 65 del; 195 mod
  Patch: https://git.openjdk.org/jdk22/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/83/head:pull/83

PR: https://git.openjdk.org/jdk22/pull/83

From redestad at openjdk.org  Tue Jan 16 18:03:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 16 Jan 2024 18:03:34 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v2]
In-Reply-To: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
Message-ID: <eTqrjam220wgmfF-UV8_l4nqDtUTQznSzUL52ccsIPk=.ccc935b8-681c-4d52-a4bc-65396ff89fa3@github.com>

> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
> 
> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Named offsets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17443/files
  - new: https://git.openjdk.org/jdk/pull/17443/files/591047b1..7df80e39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=00-01

  Stats: 14 lines in 1 file changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17443/head:pull/17443

PR: https://git.openjdk.org/jdk/pull/17443

From jlaskey at openjdk.org  Tue Jan 16 18:08:22 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 16 Jan 2024 18:08:22 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v2]
In-Reply-To: <eTqrjam220wgmfF-UV8_l4nqDtUTQznSzUL52ccsIPk=.ccc935b8-681c-4d52-a4bc-65396ff89fa3@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
 <eTqrjam220wgmfF-UV8_l4nqDtUTQznSzUL52ccsIPk=.ccc935b8-681c-4d52-a4bc-65396ff89fa3@github.com>
Message-ID: <wMSfX5J1EdYBFVJ9QCkmM9VxeeTlNuJ6cqWA1nhwU7c=.c602331b-fbb1-4bdc-9083-675efc71326b@github.com>

On Tue, 16 Jan 2024 18:03:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
>> 
>> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Named offsets

LGTM

-------------

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17443#pullrequestreview-1824485331

From mchung at openjdk.org  Tue Jan 16 18:19:19 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 16 Jan 2024 18:19:19 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v2]
In-Reply-To: <eTqrjam220wgmfF-UV8_l4nqDtUTQznSzUL52ccsIPk=.ccc935b8-681c-4d52-a4bc-65396ff89fa3@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
 <eTqrjam220wgmfF-UV8_l4nqDtUTQznSzUL52ccsIPk=.ccc935b8-681c-4d52-a4bc-65396ff89fa3@github.com>
Message-ID: <Fz6FLdG1ly5kANduiMcbnw-gRwxfCReDiAeTliYtgzY=.af5cb472-f318-4914-9309-257ac2bc63f2@github.com>

On Tue, 16 Jan 2024 18:03:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
>> 
>> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Named offsets

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17443#pullrequestreview-1824528708

From lancea at openjdk.org  Tue Jan 16 18:27:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 16 Jan 2024 18:27:25 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v4]
In-Reply-To: <Airpkbb74hed7sPRNLTr7uVs5Qon5SNKCfDjMYyGJHY=.d2d39b82-4ddf-4511-898c-de0c48318277@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <Airpkbb74hed7sPRNLTr7uVs5Qon5SNKCfDjMYyGJHY=.d2d39b82-4ddf-4511-898c-de0c48318277@github.com>
Message-ID: <g0Pykby5TiC7DYgoY237UvcrgaMWlVuXqV4EF5GxlJg=.2cd923e3-cbd5-4e0e-bb7b-71e5b1ca8578@github.com>

On Mon, 15 Jan 2024 10:26:53 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once.
>> 
>> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
>> 
>> This fix is to move the closing of the wrapped stream inside the finally block.
>> 
>> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?)
>> 
>> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
>> 
>> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
>> 
>> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/util/zip/ZipOutputStream/CloseWrappedStream.java
>   
>   Remove extra whitespace
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

The changes look good overall.    See suggestion for comment improvement  but not  required, just makes it clearer

test/jdk/java/util/zip/ZipOutputStream/CloseWrappedStream.java line 91:

> 89:     /**
> 90:      * Check that the exception handling is correct when the
> 91:      * wrapped stream throws while being closed

This comment could use a bit of wordsmithing to indicate what "correct" means

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17209#pullrequestreview-1824541172
PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1453817997

From redestad at openjdk.org  Tue Jan 16 18:42:59 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 16 Jan 2024 18:42:59 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v3]
In-Reply-To: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
Message-ID: <Jj3MQCZ_TtHwkX8BOxRBNp5eoQyIcXa7uB7VzkL4SZA=.399972d7-a227-4389-ba5b-dc8e17c451fc@github.com>

> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
> 
> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyrights, unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17443/files
  - new: https://git.openjdk.org/jdk/pull/17443/files/7df80e39..a65ffbf5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=01-02

  Stats: 17 lines in 8 files changed: 0 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17443/head:pull/17443

PR: https://git.openjdk.org/jdk/pull/17443

From darcy at openjdk.org  Tue Jan 16 18:50:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Jan 2024 18:50:34 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <WOlF2LGtzVD6vNy1WwGCBB_2KLiJhkrXsJ_wVrjHSf0=.c5c8a388-df0a-4f29-89a6-adc5deea0dde@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
 <iiXBJ-r0vq2JJCPTB2iIV5oTi4JNmNDkO1V5CFPd_p8=.ff7b9633-f4f4-492a-8ddc-56033ba2e997@github.com>
 <WOlF2LGtzVD6vNy1WwGCBB_2KLiJhkrXsJ_wVrjHSf0=.c5c8a388-df0a-4f29-89a6-adc5deea0dde@github.com>
Message-ID: <_S2q64_3F7rEX77t35YSx2OBBcJKJrpltsYAYvgK_ls=.eedf1a37-931a-4603-9988-3755f87157e6@github.com>

On Mon, 15 Jan 2024 09:49:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > With my CSR hat on, JDK-8301341 should never have made the changes it did without going through a CSR request. We have been bitten by this kind of problem many times. Unless a public method is specified to utilise another public method, we should never implement one public method in terms of another (non-final one) due to the overriding problem.
> 
> JDK-8301341 was a big update, a lot of refactoring to hollow out SQ and it was just an oversight that we didn't spot the methods now use an overridable method. It's something to always look out for in the collections area, just missed here.

We can and have run retroactive CSRs in cases like this before; I recommend we do one now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1894323864

From henryjen at openjdk.org  Tue Jan 16 19:05:44 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 16 Jan 2024 19:05:44 GMT
Subject: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1 [v2]
In-Reply-To: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
References: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
Message-ID: <v8-Lb3uuLFxIPVK7G_MZ0881_RY30FCXsCcnJhPQOQI=.29f8b19f-5e9a-4226-9762-249678dac06a@github.com>

> CPU24_01 fixes.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into cpu2401
 - 8317547: Enhance TLS connection support
   
   Reviewed-by: ahgross, rhalade, weijun, valeriep
 - 8314307: Improve loop handling
   
   Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
   Co-authored-by: Roland Westrelin <rwestrel at redhat.com>
   Co-authored-by: Emanuel Peter <epeter at openjdk.org>
   Reviewed-by: mschoene, rhalade, thartmann, epeter
 - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
   
   Reviewed-by: epeter
 - 8314468: Improve Compiler loops
   
   Co-authored-by: Dean Long <dlong at openjdk.org>
   Reviewed-by: rhalade, mschoene, iveresov, kvn
 - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
   
   Backport-of: 852276d1f833d49802693f2a5a82ba6eb2722de6
 - 8314295: Enhance verification of verifier
   
   Reviewed-by: mschoene, rhalade, dholmes, dlong
 - 8308204: Enhanced certificate processing
   
   Reviewed-by: mschoene, rhalade, jnimeh

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17448/files
  - new: https://git.openjdk.org/jdk/pull/17448/files/bf7bd9a1..e4e0d987

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17448&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17448&range=00-01

  Stats: 484 lines in 21 files changed: 304 ins; 157 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17448/head:pull/17448

PR: https://git.openjdk.org/jdk/pull/17448

From alanb at openjdk.org  Tue Jan 16 19:12:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jan 2024 19:12:04 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v3]
In-Reply-To: <_S2q64_3F7rEX77t35YSx2OBBcJKJrpltsYAYvgK_ls=.eedf1a37-931a-4603-9988-3755f87157e6@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <V8VoRdjagR51mKv6Gu95kwoKYhijNGJTuxglZnUaQHw=.c65e5448-8596-43ac-bd77-d67ef4ba081b@github.com>
 <iiXBJ-r0vq2JJCPTB2iIV5oTi4JNmNDkO1V5CFPd_p8=.ff7b9633-f4f4-492a-8ddc-56033ba2e997@github.com>
 <WOlF2LGtzVD6vNy1WwGCBB_2KLiJhkrXsJ_wVrjHSf0=.c5c8a388-df0a-4f29-89a6-adc5deea0dde@github.com>
 <_S2q64_3F7rEX77t35YSx2OBBcJKJrpltsYAYvgK_ls=.eedf1a37-931a-4603-9988-3755f87157e6@github.com>
Message-ID: <iIMICQ4qAvfjpbu4UdsYx-2dl9JcRtVK7CmggsUCpEg=.ff7e593b-9495-44c6-b3a6-46d84ff24c5b@github.com>

On Tue, 16 Jan 2024 18:47:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> We can and have run retroactive CSRs in cases like this before; I recommend we do one now.

Yes although the issue will be mute once JDK-8323659 is integrated into jdk22.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1894345385

From mchung at openjdk.org  Tue Jan 16 20:53:50 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 16 Jan 2024 20:53:50 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v3]
In-Reply-To: <Jj3MQCZ_TtHwkX8BOxRBNp5eoQyIcXa7uB7VzkL4SZA=.399972d7-a227-4389-ba5b-dc8e17c451fc@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
 <Jj3MQCZ_TtHwkX8BOxRBNp5eoQyIcXa7uB7VzkL4SZA=.399972d7-a227-4389-ba5b-dc8e17c451fc@github.com>
Message-ID: <br3nVc5MO5AQeVZjmNH0whLKXryFhjEbJrI9-OEdN1c=.ea664296-f6ef-4282-b488-74aeacc604bc@github.com>

On Tue, 16 Jan 2024 18:42:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
>> 
>> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights, unused imports

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17443#pullrequestreview-1824981642

From jlu at openjdk.org  Tue Jan 16 22:07:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Jan 2024 22:07:59 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>

On Sun, 14 Jan 2024 15:32:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Hi Archie, thanks for the proposed fix. I am still taking a look, but I wanted to demonstrate a current issue,

(Jshell with your patch)


var pattIn = "Test: {0,number,foo'{'#.00}";
MessageFormat mFmt = new MessageFormat(pattIn);
var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo{#.00}";



var pattIn = "Test: {0,number,foo'}'#.00}";
MessageFormat mFmt = new MessageFormat(pattIn);
var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo'}'#.00}";


As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted. 

Also in response to your earlier question on core-libs-dev, ideally invoking toPattern() can roundtrip, but there are known issues, such as a custom user defined Format subclass, or one of the newer Format subclasses that do not implement the toPattern() method. I am working on making this apparent in the specification of the method in a separate issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1894594743

From jlu at openjdk.org  Tue Jan 16 22:13:04 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Jan 2024 22:13:04 GMT
Subject: [jdk22] Integrated: 8322235: Split up and improve LocaleProvidersRun
In-Reply-To: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
References: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
Message-ID: <z82E2vFsyIwuClqEqGTj5_H3eWjyTxSXVT1B4_vPr2g=.c39852e7-bd9b-4d7f-832b-13985e14fe34@github.com>

On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

This pull request has now been integrated.

Changeset: b9a535b8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b9a535b8ac2e7bd5c7c2e56c1b0a498fa9c94d2a
Stats:     569 lines in 8 files changed: 425 ins; 85 del; 59 mod

8322235: Split up and improve LocaleProvidersRun

Reviewed-by: naoto, iris
Backport-of: 4ea7b36447ea96d62b1ca164c34e2b2b74a16579

-------------

PR: https://git.openjdk.org/jdk22/pull/68

From kvn at openjdk.org  Tue Jan 16 22:31:30 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Jan 2024 22:31:30 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <NJLCQ2owxIRhvMB0BD30W54fweAxjriv566eOLIn46g=.cc69ef67-e105-4667-afb1-799a62570975@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4111:

> 4109:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {
> 4110:     StubRoutines::_string_indexof = generate_string_indexof();
> 4111:   }

What motivation for this extensive new code only for avx2? 30% is nice (for some cases) but it is enabled only for AVX2 and not for avx512 which all modern x86 CPUs have so the code will not be used.

Or it is typo?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1454139710

From sgibbons at openjdk.org  Tue Jan 16 23:53:53 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 16 Jan 2024 23:53:53 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <NJLCQ2owxIRhvMB0BD30W54fweAxjriv566eOLIn46g=.cc69ef67-e105-4667-afb1-799a62570975@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <NJLCQ2owxIRhvMB0BD30W54fweAxjriv566eOLIn46g=.cc69ef67-e105-4667-afb1-799a62570975@github.com>
Message-ID: <CKcYjRj6Q4LMhvfWX9izB0ijRz22n3ehdmuU2pFlug0=.7f36882e-f376-4264-a291-b845b9645b65@github.com>

On Tue, 16 Jan 2024 22:27:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4111:
> 
>> 4109:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {
>> 4110:     StubRoutines::_string_indexof = generate_string_indexof();
>> 4111:   }
> 
> What motivation for this extensive new code only for avx2? 30% is nice (for some cases) but it is enabled only for AVX2 and not for avx512 which all modern x86 CPUs have so the code will not be used.
> 
> Or it is typo?

This is acceleration for AVX2, replacing the pcmpestri instruction which is microcoded on E-cores and causes significant performance impact.  I am working on a pared-down implementation and should update this PR in a couple of days.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1454217437

From chegar at openjdk.org  Tue Jan 16 23:58:55 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Tue, 16 Jan 2024 23:58:55 GMT
Subject: [jdk22] Integrated: 8323659: LinkedTransferQueue add and put methods
 call overridable offer
In-Reply-To: <6-eQOqLF0g-qsPb7gisku6DUuhMuJ_AYva4CUXedlYo=.f1a6d923-92f7-4377-91f4-3e558c0de778@github.com>
References: <6-eQOqLF0g-qsPb7gisku6DUuhMuJ_AYva4CUXedlYo=.f1a6d923-92f7-4377-91f4-3e558c0de778@github.com>
Message-ID: <_Zv6HVDar5QF5ZytcgB-oK2z5Cn-TFkfifFK6ed1lfA=.c8caf28e-c57a-49de-b4da-cc4c66df39f4@github.com>

On Tue, 16 Jan 2024 12:23:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 16 Jan 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: c1ea6daa
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/c1ea6daa5bd3ecee4fd3f8acaf91dfa48ec02f1b
Stats:     75 lines in 2 files changed: 72 ins; 0 del; 3 mod

8323659: LinkedTransferQueue add and put methods call overridable offer

Reviewed-by: alanb
Backport-of: ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7

-------------

PR: https://git.openjdk.org/jdk22/pull/80

From chegar at openjdk.org  Wed Jan 17 00:05:07 2024
From: chegar at openjdk.org (Chris Hegarty)
Date: Wed, 17 Jan 2024 00:05:07 GMT
Subject: RFR: 8323659: LinkedTransferQueue add and put methods call
 overridable offer [v7]
In-Reply-To: <_uYt4yx2EmiBRwC_aItraPTBrieQCbCPXBihcenA_kk=.755f283c-b9bf-4ad1-9782-222424373e8d@github.com>
References: <gKRs7CbzlTo4lfqsWOLKGpO2L4N0HHQfzrya0glqDA8=.5f70aa15-25e8-4351-bc29-da38c97e963a@github.com>
 <_uYt4yx2EmiBRwC_aItraPTBrieQCbCPXBihcenA_kk=.755f283c-b9bf-4ad1-9782-222424373e8d@github.com>
Message-ID: <ICKAkiFE25-BHXrzvD8cf-Xb6-digkIb7cP4OLYbTjk=.617d80b6-fc2a-4ce5-a876-beb351cb848d@github.com>

On Tue, 16 Jan 2024 09:11:01 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into ltq_bug
>  - Merge branch 'master' into ltq_bug
>  - order of tags
>  - Merge branch 'master' into ltq_bug
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - timed offer
>  - add test
>  - Update LinkedTransferQueue add and put methods to not call overridable offer

I just integrated the fix into jdk 22, so we?re good there now.

The final piece of the puzzle is jdk 21.0.2, which we?re too late to fix. We can add a release note, and fix it in 21.0.3. Any objections or alternative suggestions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17393#issuecomment-1894710437

From kvn at openjdk.org  Wed Jan 17 00:15:52 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 17 Jan 2024 00:15:52 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <CKcYjRj6Q4LMhvfWX9izB0ijRz22n3ehdmuU2pFlug0=.7f36882e-f376-4264-a291-b845b9645b65@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <NJLCQ2owxIRhvMB0BD30W54fweAxjriv566eOLIn46g=.cc69ef67-e105-4667-afb1-799a62570975@github.com>
 <CKcYjRj6Q4LMhvfWX9izB0ijRz22n3ehdmuU2pFlug0=.7f36882e-f376-4264-a291-b845b9645b65@github.com>
Message-ID: <pUubxYQ_lbOg9Kn9zuku8LjVLoPWjb8Qem4F-fUcvGE=.917c89ad-2e75-401d-a7cf-3af938a7a39a@github.com>

On Tue, 16 Jan 2024 23:51:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4111:
>> 
>>> 4109:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {
>>> 4110:     StubRoutines::_string_indexof = generate_string_indexof();
>>> 4111:   }
>> 
>> What motivation for this extensive new code only for avx2? 30% is nice (for some cases) but it is enabled only for AVX2 and not for avx512 which all modern x86 CPUs have so the code will not be used.
>> 
>> Or it is typo?
>
> This is acceleration for AVX2, replacing the pcmpestri instruction which is microcoded on E-cores and causes significant performance impact.  I am working on a pared-down implementation and should update this PR in a couple of days.

Thank you for explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1454238988

From redestad at openjdk.org  Wed Jan 17 00:56:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Jan 2024 00:56:30 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v4]
In-Reply-To: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
Message-ID: <VrJ8lLNEIECH_JkAgyKTMZyTOCez-iAA6wyqrdr1A2s=.8750aaaf-2394-49e0-a3b8-4a26f639711a@github.com>

> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
> 
> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Wrong order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17443/files
  - new: https://git.openjdk.org/jdk/pull/17443/files/a65ffbf5..d1917182

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17443/head:pull/17443

PR: https://git.openjdk.org/jdk/pull/17443

From erikj at openjdk.org  Wed Jan 17 01:24:51 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 01:24:51 GMT
Subject: RFR: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1 [v2]
In-Reply-To: <v8-Lb3uuLFxIPVK7G_MZ0881_RY30FCXsCcnJhPQOQI=.29f8b19f-5e9a-4226-9762-249678dac06a@github.com>
References: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
 <v8-Lb3uuLFxIPVK7G_MZ0881_RY30FCXsCcnJhPQOQI=.29f8b19f-5e9a-4226-9762-249678dac06a@github.com>
Message-ID: <r0EbQezCIfQZkN9CaEpnq4_vChupoB5Ur0AW3mvGZWo=.3df93068-5d9e-4428-adfe-603b0806f357@github.com>

On Tue, 16 Jan 2024 19:05:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> CPU24_01 fixes.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into cpu2401
>  - 8317547: Enhance TLS connection support
>    
>    Reviewed-by: ahgross, rhalade, weijun, valeriep
>  - 8314307: Improve loop handling
>    
>    Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
>    Co-authored-by: Roland Westrelin <rwestrel at redhat.com>
>    Co-authored-by: Emanuel Peter <epeter at openjdk.org>
>    Reviewed-by: mschoene, rhalade, thartmann, epeter
>  - 8318588: Windows build failure after JDK-8314468 due to ambiguous call
>    
>    Reviewed-by: epeter
>  - 8314468: Improve Compiler loops
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: rhalade, mschoene, iveresov, kvn
>  - 8317331: Solaris build failed with "declaration can not follow a statement (E_DECLARATION_IN_CODE)"
>    
>    Backport-of: 852276d1f833d49802693f2a5a82ba6eb2722de6
>  - 8314295: Enhance verification of verifier
>    
>    Reviewed-by: mschoene, rhalade, dholmes, dlong
>  - 8308204: Enhanced certificate processing
>    
>    Reviewed-by: mschoene, rhalade, jnimeh

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17448#pullrequestreview-1826181933

From erikj at openjdk.org  Wed Jan 17 01:25:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 01:25:54 GMT
Subject: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b
In-Reply-To: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
References: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
Message-ID: <mzRza8OOWjcx6RzOh9TAlJtPpvmtl0w2Rnklnef1RxU=.c5625fe7-5cb6-43a0-a685-8055b8d27c69@github.com>

On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> CPU24_01 fixes.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/83#pullrequestreview-1826185706

From henryjen at openjdk.org  Wed Jan 17 01:45:03 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 17 Jan 2024 01:45:03 GMT
Subject: Integrated: Merge bf7bd9a16c172bcb5ea6b24717a0429e12e2e3d1
In-Reply-To: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
References: <VMLgftZS3gowdkprzSZDazumtEryDvNeAszMit9wB6k=.5e0b2f20-ff5e-4c53-a73c-f4a0bf6e7edd@github.com>
Message-ID: <3HvjxNSJNsiVEgttXj91XvlqSDmGh_ZGJxcDh0qNzgo=.51d3fa63-788a-47db-ad1c-4db8b68aae1b@github.com>

On Tue, 16 Jan 2024 16:32:27 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> CPU24_01 fixes.

This pull request has now been integrated.

Changeset: 2063bb8f
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2063bb8ffabd6096f547ec6da979cfcf68a56ba3
Stats:     736 lines in 16 files changed: 476 ins; 65 del; 195 mod

Merge

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/17448

From henryjen at openjdk.org  Wed Jan 17 01:45:28 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 17 Jan 2024 01:45:28 GMT
Subject: [jdk22] RFR: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b [v2]
In-Reply-To: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
References: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
Message-ID: <QPQKSvhJBUqBSv7cPBwOniB0MzpJvs3GgYfEqQQ_CJk=.9f42545c-26a7-4009-b0cf-f5f530f26532@github.com>

> CPU24_01 fixes.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk22/pull/83/files
  - new: https://git.openjdk.org/jdk22/pull/83/files/c7f1c973..c7f1c973

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk22&pr=83&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk22&pr=83&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk22/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/83/head:pull/83

PR: https://git.openjdk.org/jdk22/pull/83

From henryjen at openjdk.org  Wed Jan 17 01:45:29 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 17 Jan 2024 01:45:29 GMT
Subject: [jdk22] Integrated: Merge c7f1c97312f94b6dd6398a5e98dd0c8b63db4c9b
In-Reply-To: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
References: <OMBDfLOMu27dF8r6XrDSrNg-4B8eNyo-MgOk1JV8sKc=.68797a05-c82e-40f0-8b2c-0777b364d770@github.com>
Message-ID: <GQunM3ZjKmQcjUS8Qs5-khmA4iKShEB9khxkymhEDRM=.fc527ecf-e394-4e5e-9a7c-7646254371c1@github.com>

On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> CPU24_01 fixes.

This pull request has now been integrated.

Changeset: b2cc1890
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b2cc1890ff4d2e5404e153ecba5e83f1bcdd6fa7
Stats:     736 lines in 16 files changed: 476 ins; 65 del; 195 mod

Merge

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk22/pull/83

From asotona at openjdk.org  Wed Jan 17 08:32:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Jan 2024 08:32:59 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: <a3DCIaX_uJ7WBhTp-slq0QQiHJ44333E3ybzYtGYCtc=.6c1ca6f0-000d-427a-ad8a-c46c545fbe33@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

Yes, CodeBuilder method renames will require some refactoring.
This is good.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13009#pullrequestreview-1826743185

From rrich at openjdk.org  Wed Jan 17 09:37:20 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 17 Jan 2024 09:37:20 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin
Message-ID: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>

Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).

The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

-------------

Commit messages:
 - New version of LotsOfInterrupts.java supporting virtual threads
 - Add Alan's LotsOfInterrupts.java test
 - Must checkAccess before changing interrupt state of other thread
 - 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin

Changes: https://git.openjdk.org/jdk/pull/17444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323782
  Stats: 101 lines in 2 files changed: 95 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17444/head:pull/17444

PR: https://git.openjdk.org/jdk/pull/17444

From rrich at openjdk.org  Wed Jan 17 09:37:20 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 17 Jan 2024 09:37:20 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin
In-Reply-To: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
Message-ID: <nOTXTDF-E0T1pRm0dF16310ucC6-NfLi5QQyAjq-TP0=.bf46090b-3fb8-4069-8b2d-7416dd674caf@github.com>

On Tue, 16 Jan 2024 10:57:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
> 
> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

Thanks for the test @AlanBateman

The new test LotsOfInterrupts.java hangs after a few repetitions (using jtreg's REPEAT_COUNT). With the fix it always terminates successfully.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1894154593
PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1894211061

From pminborg at openjdk.org  Wed Jan 17 10:38:54 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 Jan 2024 10:38:54 GMT
Subject: [jdk22] Integrated: 8323159: Consider adding some text re. memory
 zeroing in Arena::allocate
In-Reply-To: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
References: <6b6IzZv0HFgUYt6JO9agjpcQNu68DM0I4lzQ85oLCJg=.50836685-9dc0-4f0b-a98a-49fe7f9a40b5@github.com>
Message-ID: <XxQAY7VGpQLbbcULZNAyQR8lz2ycaFDt403MTHuHKsM=.5fe04da3-472e-4359-a7b4-c625c3125684@github.com>

On Mon, 15 Jan 2024 16:14:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> 8323159: Consider adding some text re. memory zeroing in Arena::allocate

This pull request has now been integrated.

Changeset: 887a93b7
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/887a93b7c949308b83d4feba714682e8962a3556
Stats:     51 lines in 2 files changed: 49 ins; 0 del; 2 mod

8323159: Consider adding some text re. memory zeroing in Arena::allocate
8323745: Missing comma in copyright header in TestScope

Reviewed-by: mcimadamore, alanb
Backport-of: f5b757ced6b672010ea10575d644d3f9d1728923

-------------

PR: https://git.openjdk.org/jdk22/pull/77

From redestad at openjdk.org  Wed Jan 17 10:41:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Jan 2024 10:41:07 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v5]
In-Reply-To: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
Message-ID: <N2zkfXfEgAooFc1U23t7lMi6tJju1AjK8fTXkWu3_AY=.bdeb340d-7a83-440a-bc11-9b6571bc9bb9@github.com>

> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
> 
> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Missed a Properties argument in CompressorPluginTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17443/files
  - new: https://git.openjdk.org/jdk/pull/17443/files/d1917182..0dad1af3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17443&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17443/head:pull/17443

PR: https://git.openjdk.org/jdk/pull/17443

From redestad at openjdk.org  Wed Jan 17 10:53:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Jan 2024 10:53:50 GMT
Subject: RFR: 8323794: Remove unused jimage compressor plugin configuration
 [v5]
In-Reply-To: <N2zkfXfEgAooFc1U23t7lMi6tJju1AjK8fTXkWu3_AY=.bdeb340d-7a83-440a-bc11-9b6571bc9bb9@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
 <N2zkfXfEgAooFc1U23t7lMi6tJju1AjK8fTXkWu3_AY=.bdeb340d-7a83-440a-bc11-9b6571bc9bb9@github.com>
Message-ID: <K4-v2Kti0fnxhakabBMMzZFio5NKszxu6St6rUkZYpA=.cea6ffa6-c3d7-4b0f-9936-40bba1aa09bd@github.com>

On Wed, 17 Jan 2024 10:41:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
>> 
>> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a Properties argument in CompressorPluginTest

Thanks for reviewing and re-reviewing! I caught and fixed a few issues in testing (tier1-4), extending pre-integration testing to tier5 and taking another manual pass over all related tests before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17443#issuecomment-1895560774

From rgiulietti at openjdk.org  Wed Jan 17 11:04:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 Jan 2024 11:04:54 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v15]
In-Reply-To: <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <JRiCh1L3ApPrdC3Tp3gdMRm6oYbWrWjxf6LZqUIhNSo=.59d99dd8-1a63-4e48-b96e-2a8bf6aa69d8@github.com>
Message-ID: <WnZ-Tk9FvlewohU_YuzvM9nKmJ15WvM5MMh6jPIrs6w=.bab71357-4b26-4d15-b147-bfed604139bd@github.com>

On Mon, 15 Jan 2024 14:17:40 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 useless event settings in test.

I plan to integrate the last commit by tomorrow, provided `security` folks do not disagree.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1895579331

From shade at openjdk.org  Wed Jan 17 12:12:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Jan 2024 12:12:52 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <gP8SIC8S4GydxFfWZrZJLl-eI8n3tHluDYh7AIjSH2o=.50fb00c7-4556-4dc5-a879-012e7fe80764@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Any other reviews needed for this? Nominally, this changes the test groups in langtools, so maybe @lahodaj or @biboudis want to take a look. For jaxp, @JoeWang-Java, maybe?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1895680732

From duke at openjdk.org  Wed Jan 17 12:14:59 2024
From: duke at openjdk.org (Glavo)
Date: Wed, 17 Jan 2024 12:14:59 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v6]
In-Reply-To: <s_E-9uqQlS4Ri6kqN6s7cQqIqnF7MDQa6fcB5Ya64dA=.d4ec91a5-5e70-4f2a-9567-9c819012f2a3@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <3t7-samFVSG-gKrTp9-slrWbUqk0zCO_JzNJtlpPKXE=.5dbb8f64-f1b2-49d6-8f18-8f1451e77006@github.com>
 <s_E-9uqQlS4Ri6kqN6s7cQqIqnF7MDQa6fcB5Ya64dA=.d4ec91a5-5e70-4f2a-9567-9c819012f2a3@github.com>
Message-ID: <DgFZ-TqaYj0XZtSYAz0naWpBEEhuoCcXtN96UDvqPuU=.f2f32bb5-5de7-472f-a52b-bab89d9dee4d@github.com>

On Tue, 16 Jan 2024 15:16:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into zip-utils
>>  - Merge branch 'openjdk:master' into zip-utils
>>  - Merge branch 'openjdk:master' into zip-utils
>>  - Merge branch 'openjdk:master' into zip-utils
>>  - Merge branch 'openjdk:master' into zip-utils
>>  - use ByteArrayLittleEndian in ZipUtils
>
> Hello Glavo, I see that you are interested in pursuing this change further. Would you mind getting the latest micro benchmark numbers which this proposed change? I see that your PR description has a run from some time back, getting a latest one would be useful.
> 
> Additionally, I see that https://github.com/openjdk/jdk/pull/14636 where you had proposed a test case for the `ByteArrayLittleEndian` class (in addition to other things) got closed without being integrated. Would you mind adding a new test case for that class as part of this current PR since you have a few more new methods being added to that class?

@jaikiran Can you review this PR again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1895683407

From jlaskey at openjdk.org  Wed Jan 17 14:28:20 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 17 Jan 2024 14:28:20 GMT
Subject: [jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly
 after toString() was called
Message-ID: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>

The new repeat methods were not clearing the toStringCache.

-------------

Commit messages:
 - Backport df22fb322e6c4c9931a770bd0abf4c43b83c4e4a

Changes: https://git.openjdk.org/jdk22/pull/87/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=87&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/jdk22/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/87/head:pull/87

PR: https://git.openjdk.org/jdk22/pull/87

From prappo at openjdk.org  Wed Jan 17 14:30:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Jan 2024 14:30:53 GMT
Subject: [jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly
 after toString() was called
In-Reply-To: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
References: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
Message-ID: <qKnWBbtuIHMrlELqNJ734vVUaTryNyXdVB_xrCIQPEU=.f2479db3-7ef8-44c5-b124-51a241119ea2@github.com>

On Wed, 17 Jan 2024 14:21:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The new repeat methods were not clearing the toStringCache.

Seems like a clean backport of a P3 bug from mainline to jdk 22, just in time before RDP 2.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/87#pullrequestreview-1827429912

From prappo at openjdk.org  Wed Jan 17 14:39:50 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Jan 2024 14:39:50 GMT
Subject: [jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly
 after toString() was called
In-Reply-To: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
References: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
Message-ID: <R1AVJ9zDyK6oKPK6a5qPnthlelIeW8mghmW9bma0w50=.5181a3a7-5f0b-4b64-bcf4-11e9fe9729c7@github.com>

On Wed, 17 Jan 2024 14:21:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The new repeat methods were not clearing the toStringCache.

Jim, note that the bot said this:

> At the time when this comment was updated there had been 64 new commits pushed to the master branch:

I'm not sure why there's such a big divergence, but if I were you, I'd be testing this change extra carefully before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk22/pull/87#issuecomment-1895943189

From jlaskey at openjdk.org  Wed Jan 17 15:01:07 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 17 Jan 2024 15:01:07 GMT
Subject: [jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly
 after toString() was called [v2]
In-Reply-To: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
References: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
Message-ID: <9-Z5ml1cvqO-Udhm2UNYBC499nJ4l2g_1pO1SdANjto=.5032cfc5-331c-4624-8717-2188edccc6dd@github.com>

> The new repeat methods were not clearing the toStringCache.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into backport-JimLaskey-df22fb32
 - Backport df22fb322e6c4c9931a770bd0abf4c43b83c4e4a

-------------

Changes:
  - all: https://git.openjdk.org/jdk22/pull/87/files
  - new: https://git.openjdk.org/jdk22/pull/87/files/e9817489..0ae24358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk22&pr=87&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk22&pr=87&range=00-01

  Stats: 7075 lines in 237 files changed: 4658 ins; 1464 del; 953 mod
  Patch: https://git.openjdk.org/jdk22/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/87/head:pull/87

PR: https://git.openjdk.org/jdk22/pull/87

From alanb at openjdk.org  Wed Jan 17 15:20:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Jan 2024 15:20:56 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin
In-Reply-To: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
Message-ID: <6eK7BRD446_zEal2yY4WyQ2bJNgAMdJnhbfPbJedOZ8=.d08e0584-d99b-483e-9d1d-f7ec443370f0@github.com>

On Tue, 16 Jan 2024 10:57:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
> 
> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

Thanks for finding this issue. It duplicates on JDK 8, and looking at the ancient history, it looks like it's been there since JDK 1.4 but just not noticed or diagnosed.

Reading the nioBlocker after setting the interrupt status is good. 

There are about 20 tests for async interrupt of I/O ops in tier2. I see you've run tier1-4 so you've run them.

src/java.base/share/classes/java/lang/Thread.java line 1706:

> 1704:             checkAccess();
> 1705:         }
> 1706:         // Write interrupted before reading nioBlocker for correct synchronization.

I think I'd prefer if this said that it sets the interrupt status, and must be done before reading the nioBlocker.

src/java.base/share/classes/java/lang/Thread.java line 1710:

> 1708:         interrupt0();  // inform VM of interrupt
> 1709:         if (this != Thread.currentThread()) {
> 1710:             // thread may be blocked in an I/O operation

I think the existing comment "thread may be blocked in an I/O operation" can move to before the `if` statement so that it's a bit clearer than this is code for I/O operations.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17444#pullrequestreview-1827537664
PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1455826929
PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1455825649

From rrich at openjdk.org  Wed Jan 17 15:38:22 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 17 Jan 2024 15:38:22 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
Message-ID: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>

> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
> 
> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Review Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17444/files
  - new: https://git.openjdk.org/jdk/pull/17444/files/2c1d3835..ab3513c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17444&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17444&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17444/head:pull/17444

PR: https://git.openjdk.org/jdk/pull/17444

From forax at univ-mlv.fr  Wed Jan 17 15:38:56 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 Jan 2024 16:38:56 +0100 (CET)
Subject: Improving the Gatherer public API
Message-ID: <990399866.105046056.1705505936271.JavaMail.zimbra@univ-eiffel.fr>

Hello,
i've played quite a lot with the Gatherer API and overall, i quite like how things work conceptually.
But i think the public API can be improved.


First, the documentation is not fully clear that a Gatherer has 3 characteristics,
1/ Is it sequential or parallelizable (can be parallel is ask)
2/ Is it stateless or stateful
3/ Is the integrator greedy or not.

There is also, is there a finisher or not, but this is less important.

When creating a Gatherer, a user can find the right method "Gatherer.of" by following this state diagram

    // if sequential
      // if stateless
        // if greedy
        Gatherer.ofSequential(Gatherer.Integrator.ofGreedy(integrator), finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(integrator, finisher?)
      // otherwise statefull
        // if greedy
        Gatherer.ofSequential(initializer, Gatherer.Integrator.ofGreedy(integrator), finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(initializer, integrator, finisher?)
    // otherwise parallelizable
      // if stateless
        // if greedy
        Gatherer.of(Gatherer.Integrator.ofGreedy(integrator), finisher?)
        // otherwise short-circuit
        Gatherer.of(integrator, finisher?)
      // otherwise stateful
        // if greedy
        Gatherer.of(initializer, Gatherer.Integrator.ofGreedy(integrator), combiner, finisher)
        // otherwise short-circuit
        Gatherer.of(initializer, integrator, combiner, finisher)

The first issue I stumble several time is that i've forgotten to use Integrator.ofGreedy(). I'm not the only one, at least both Viktor and Nicolai Parlog had the same issue. It's to easy to forget to call Integrator.ofGreedy().

I think the API should be slightly modified to force the user to make a choice between greedy or short-cuircuit.

I'm proposing to add a new parameter for all the factory methods, in front of the integrator, forcing the user to make a choice
  enum IntegratorKind {
    GREEDY, SHORT_CIRCUIT
  }

so the state diagram becomes

    // if sequential
      // if stateless
        // if greedy
        Gatherer.ofSequential(GREEDY, integrator, finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(SHORT_CIRCUIT, integrator, finisher?)
      // otherwise stateful
        // if greedy
        Gatherer.ofSequential(initializer, GREEDY, integrator, finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(initializer, SHORT_CIRCUIT, integrator, finisher?)
    // otherwise parallelizable
      // if stateless
        // if greedy
        Gatherer.of(GREEDY, integrator, finisher?)
        // otherwise short-circuit
        Gatherer.of(SHORT_CIRCUIT, integrator, finisher?)
      // otherwise stateful
        // if greedy
        Gatherer.of(initializer, GREEDY, integrator, combiner, finisher)
        // otherwise short-circuit
        Gatherer.of(initializer, SHORT_CIRCUIT, integrator, combiner, finisher)  

The second issue is that it's hard to implement a Gatherer that itself need a Gatherer as parameter (like andThen/compose). This is due to the fact that querying if a Gatherer is SEQUENTIAL, STATELESS or GREEDY is far for obvious. Instead of having a method characteristics() like a Collector, the way to query the characteristics is very add-hoc, using either the default combiner/initializer or instanceof on the integrator. 

  SEQUENTIAL: combiner == defaultCombiner
  STATELESS:  initializer == defaultInitializer
  GREEDY: integrator instanceof Greedy

I think the API should be simple if the default combiner/initializer and finisher were removed a method characteristics (and a default method hasCHaracteristics) were added.
It would be more like a Collector, simpler to user, and the default implementation of the combiner/initializer/finisher could be an impleemntation detail instead of being part of the API.

As a side note: the exact semantics of == on a lambda is not specified so the actual implementation ask users to rely on the way the current OpenJDK implementation works.

They are more mails to come on two other issues not fully realated to the public API of the Gatherer, so i'm trying to keep the mail short.

regards,
R?mi

From alanb at openjdk.org  Wed Jan 17 15:43:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Jan 2024 15:43:53 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
Message-ID: <f5yUSywuX7NfXCwmbgjaUdYPzhkvIFseNgfYka44uG8=.3e46fd92-ff47-4862-9f80-33c0e2b1dcf7@github.com>

On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17444#pullrequestreview-1827598012

From redestad at openjdk.org  Wed Jan 17 15:44:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Jan 2024 15:44:04 GMT
Subject: Integrated: 8323794: Remove unused jimage compressor plugin
 configuration
In-Reply-To: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
References: <VaRY8NTaLQtNRiqOe5ZDPY_StZttwmyjdX0nmlQFhN8=.004743e0-d674-46fb-bd1a-6e151159c237@github.com>
Message-ID: <csEVKyYJM3vpZg8KW4RkBqLtVyFyBEAdzY0ud-9F4cE=.313a9965-a032-4fd2-b41b-f304cae5faee@github.com>

On Tue, 16 Jan 2024 10:55:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There's an unused concept of a pluginConfig that is passed into the jlink compress plugins, however we always pass null here and the code seems broken (the pluginConfig wouldn't have been stored properly). This seem to be a left-over from a more generic plugin design that never came to fruition.
> 
> This PR cleans out this code from the plugins and decompressors, while keeping the compressed header format intact for backwards compatibility (and in case we want to revisit this in the future)

This pull request has now been integrated.

Changeset: 8b29e127
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b29e127c2b030a2f63840b56c5bdecd5ee18cab
Stats:     94 lines in 13 files changed: 10 ins; 47 del; 37 mod

8323794: Remove unused jimage compressor plugin configuration

Reviewed-by: jlaskey, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/17443

From rrich at openjdk.org  Wed Jan 17 15:46:55 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 17 Jan 2024 15:46:55 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
Message-ID: <R5nazJpHysRHS6XPAQEFsYgTjq_3MV_CeeD1PLhKtGA=.3ba07213-681e-4ccd-afe6-7e3ed85facb2@github.com>

On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

Thanks for your help Alan.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1896080567

From forax at univ-mlv.fr  Wed Jan 17 15:48:46 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 Jan 2024 16:48:46 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
Message-ID: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi

From forax at univ-mlv.fr  Wed Jan 17 15:55:35 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 Jan 2024 16:55:35 +0100 (CET)
Subject: Gatherer API : wildcards complaint
Message-ID: <440278492.105063841.1705506935769.JavaMail.zimbra@univ-eiffel.fr>

Hello,
this is a minor complaint but I do not see a raison to not getting this right.

Currently the Gatherer API does not use the wildcard correctly, which is not fully an issue because there is "enough" wildcards that if you rely on the inference, it will work.

The problem is that when you write code, you make mistakes and usually when you have a typing issue, a way to debug it is to fix the type arguments de-activating the inference.
But because there are some missing wildcards, this debugging strategy just fail flat with more typing errors.

I think that fixing the missing wildcards will hep users (or a least me) to have a better experience when using the Gatherer API.

I can help and propose a PR if you want.

regards,
R?mi

From vromero at openjdk.org  Wed Jan 17 15:57:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Jan 2024 15:57:30 GMT
Subject: RFR: 8323835: Updating ASM to 9.6 for JDK 23
Message-ID: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>

Updating ASM to version 9.6,

Thanks in advance for the reviews,
Vicente

-------------

Commit messages:
 - some additional minor changes
 - more changes
 - additional changes
 - 8323835: Updating ASM to 9.6 for JDK 23

Changes: https://git.openjdk.org/jdk/pull/17453/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323835
  Stats: 1536 lines in 127 files changed: 1033 ins; 181 del; 322 mod
  Patch: https://git.openjdk.org/jdk/pull/17453.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17453/head:pull/17453

PR: https://git.openjdk.org/jdk/pull/17453

From forax at univ-mlv.fr  Wed Jan 17 16:08:00 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 Jan 2024 17:08:00 +0100 (CET)
Subject: Seing a Collector as a Gatherer
Message-ID: <485039120.105074388.1705507680624.JavaMail.zimbra@univ-eiffel.fr>

Hello,
I may have overlook that, but it seems there is no method to see a Collector as a Gatherer.

A Gatherer is more general than a Collector and a Gatherer with a greedy integrator that does not call Downstream.push in the intergator and only once is the finisher is basicaly a Collector.

In code:
<E, A, T> Gatherer<E, A, T> asGatherer(Collector<? super E, A, ? extends T> collector) {
  var supplier = collector.supplier();
  var accumulator = collector.accumulator();
  var combiner = collector.combiner();
  var finisher = collector.finisher();
  return Gatherer.of(supplier,
      Gatherer.Integrator.ofGreedy((state, element, _) -> {
        accumulator.accept(state, element);
        return true;
      }),
      combiner,
      (state, downstream) -> downstream.push(finisher.apply(state)));
}

This is eaxctly how Gatherer.fold() works.

Is there a reason why such method does not exist ?

regards,
R?mi

From viktor.klang at oracle.com  Wed Jan 17 16:49:01 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 17 Jan 2024 16:49:01 +0000
Subject: Gatherer API : wildcards complaint
In-Reply-To: <440278492.105063841.1705506935769.JavaMail.zimbra@univ-eiffel.fr>
References: <440278492.105063841.1705506935769.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774510AC07F81FCE2AA7EEDFF722@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi R?mi,

Thank you for the feedback?examples would be much appreciated!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:55
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer API : wildcards complaint

Hello,
this is a minor complaint but I do not see a raison to not getting this right.

Currently the Gatherer API does not use the wildcard correctly, which is not fully an issue because there is "enough" wildcards that if you rely on the inference, it will work.

The problem is that when you write code, you make mistakes and usually when you have a typing issue, a way to debug it is to fix the type arguments de-activating the inference.
But because there are some missing wildcards, this debugging strategy just fail flat with more typing errors.

I think that fixing the missing wildcards will hep users (or a least me) to have a better experience when using the Gatherer API.

I can help and propose a PR if you want.

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/48fded14/attachment.htm>

From viktor.klang at oracle.com  Wed Jan 17 17:02:05 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 17 Jan 2024 17:02:05 +0000
Subject: Seing a Collector as a Gatherer
In-Reply-To: <485039120.105074388.1705507680624.JavaMail.zimbra@univ-eiffel.fr>
References: <485039120.105074388.1705507680624.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774D3C2F72F8DA548660D0FFF722@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi R?mi,

Yes, this was something I was hoping to get into the preview, but I wasn't sure where that conversion should end up.

There are a few different places where it might go:

Gatherer.of(Collector)
Gatherers.collect(Collector)
Collector.asGatherer()
Collectors.gather(Collector)

I wasn't really convinced where it should go, and I was hesitant to making any changes to existing public interfaces as a "nice to have", so I opted to leave it out for now.

I think people would prefer to see it on Collector as a default method, but as I said before, making changes to Collector wasn't something I was ready to prioritize for the (first) JEP.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 17:08
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Seing a Collector as a Gatherer

Hello,
I may have overlook that, but it seems there is no method to see a Collector as a Gatherer.

A Gatherer is more general than a Collector and a Gatherer with a greedy integrator that does not call Downstream.push in the intergator and only once is the finisher is basicaly a Collector.

In code:
<E, A, T> Gatherer<E, A, T> asGatherer(Collector<? super E, A, ? extends T> collector) {
  var supplier = collector.supplier();
  var accumulator = collector.accumulator();
  var combiner = collector.combiner();
  var finisher = collector.finisher();
  return Gatherer.of(supplier,
      Gatherer.Integrator.ofGreedy((state, element, _) -> {
        accumulator.accept(state, element);
        return true;
      }),
      combiner,
      (state, downstream) -> downstream.push(finisher.apply(state)));
}

This is eaxctly how Gatherer.fold() works.

Is there a reason why such method does not exist ?

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/747f1403/attachment-0001.htm>

From viktor.klang at oracle.com  Wed Jan 17 17:02:46 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 17 Jan 2024 17:02:46 +0000
Subject: Improving the Gatherer public API
In-Reply-To: <990399866.105046056.1705505936271.JavaMail.zimbra@univ-eiffel.fr>
References: <990399866.105046056.1705505936271.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB577487720A56DF020803B67DFF722@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi R?mi,

Thanks for your thoughts!

Improving the documentation of Gatherer / Gatherers is definitely something I am intending to have inspired by feedback received as people try it out, so your thoughts here are most welcome.

For the longest time Gatherer had Characteristics (just like Collector, which Gatherer borrows its design from) but in the end it didn't carry its weight and tracking the characteristics separately from the actual behavior turned out to be a source of both poor performance (since characteristics need to be composed) and a source of subtle defects.

The concern around the identity-equals of a lambda is a bit of a non-issue since we are comparing instances of the interfaces, and the default values are not lambdaform:https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L453

PS. Forgetting ofGreedy shouldn't affect semantics, it's just an evaluation hint which can result in higher performance.

Cheers,
?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:38
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Improving the Gatherer public API

Hello,
i've played quite a lot with the Gatherer API and overall, i quite like how things work conceptually.
But i think the public API can be improved.


First, the documentation is not fully clear that a Gatherer has 3 characteristics,
1/ Is it sequential or parallelizable (can be parallel is ask)
2/ Is it stateless or stateful
3/ Is the integrator greedy or not.

There is also, is there a finisher or not, but this is less important.

When creating a Gatherer, a user can find the right method "Gatherer.of" by following this state diagram

    // if sequential
      // if stateless
        // if greedy
        Gatherer.ofSequential(Gatherer.Integrator.ofGreedy(integrator), finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(integrator, finisher?)
      // otherwise statefull
        // if greedy
        Gatherer.ofSequential(initializer, Gatherer.Integrator.ofGreedy(integrator), finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(initializer, integrator, finisher?)
    // otherwise parallelizable
      // if stateless
        // if greedy
        Gatherer.of(Gatherer.Integrator.ofGreedy(integrator), finisher?)
        // otherwise short-circuit
        Gatherer.of(integrator, finisher?)
      // otherwise stateful
        // if greedy
        Gatherer.of(initializer, Gatherer.Integrator.ofGreedy(integrator), combiner, finisher)
        // otherwise short-circuit
        Gatherer.of(initializer, integrator, combiner, finisher)

The first issue I stumble several time is that i've forgotten to use Integrator.ofGreedy(). I'm not the only one, at least both Viktor and Nicolai Parlog had the same issue. It's to easy to forget to call Integrator.ofGreedy().

I think the API should be slightly modified to force the user to make a choice between greedy or short-cuircuit.

I'm proposing to add a new parameter for all the factory methods, in front of the integrator, forcing the user to make a choice
  enum IntegratorKind {
    GREEDY, SHORT_CIRCUIT
  }

so the state diagram becomes

    // if sequential
      // if stateless
        // if greedy
        Gatherer.ofSequential(GREEDY, integrator, finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(SHORT_CIRCUIT, integrator, finisher?)
      // otherwise stateful
        // if greedy
        Gatherer.ofSequential(initializer, GREEDY, integrator, finisher?)
        // otherwise short-circuit
        Gatherer.ofSequential(initializer, SHORT_CIRCUIT, integrator, finisher?)
    // otherwise parallelizable
      // if stateless
        // if greedy
        Gatherer.of(GREEDY, integrator, finisher?)
        // otherwise short-circuit
        Gatherer.of(SHORT_CIRCUIT, integrator, finisher?)
      // otherwise stateful
        // if greedy
        Gatherer.of(initializer, GREEDY, integrator, combiner, finisher)
        // otherwise short-circuit
        Gatherer.of(initializer, SHORT_CIRCUIT, integrator, combiner, finisher)

The second issue is that it's hard to implement a Gatherer that itself need a Gatherer as parameter (like andThen/compose). This is due to the fact that querying if a Gatherer is SEQUENTIAL, STATELESS or GREEDY is far for obvious. Instead of having a method characteristics() like a Collector, the way to query the characteristics is very add-hoc, using either the default combiner/initializer or instanceof on the integrator.

  SEQUENTIAL: combiner == defaultCombiner
  STATELESS:  initializer == defaultInitializer
  GREEDY: integrator instanceof Greedy

I think the API should be simple if the default combiner/initializer and finisher were removed a method characteristics (and a default method hasCHaracteristics) were added.
It would be more like a Collector, simpler to user, and the default implementation of the combiner/initializer/finisher could be an impleemntation detail instead of being part of the API.

As a side note: the exact semantics of == on a lambda is not specified so the actual implementation ask users to rely on the way the current OpenJDK implementation works.

They are more mails to come on two other issues not fully realated to the public API of the Gatherer, so i'm trying to keep the mail short.

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/9495be72/attachment.htm>

From redestad at openjdk.org  Wed Jan 17 17:21:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Jan 2024 17:21:50 GMT
Subject: [jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly
 after toString() was called [v2]
In-Reply-To: <9-Z5ml1cvqO-Udhm2UNYBC499nJ4l2g_1pO1SdANjto=.5032cfc5-331c-4624-8717-2188edccc6dd@github.com>
References: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
 <9-Z5ml1cvqO-Udhm2UNYBC499nJ4l2g_1pO1SdANjto=.5032cfc5-331c-4624-8717-2188edccc6dd@github.com>
Message-ID: <KYyjgaVEBqVNwVluXeQQrAFIvRL9kxAvqYY28T3iK_E=.d0681a0f-cdce-4924-8865-902cb532e056@github.com>

On Wed, 17 Jan 2024 15:01:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The new repeat methods were not clearing the toStringCache.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into backport-JimLaskey-df22fb32
>  - Backport df22fb322e6c4c9931a770bd0abf4c43b83c4e4a

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/87#pullrequestreview-1827802455

From joehw at openjdk.org  Wed Jan 17 17:41:52 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 17 Jan 2024 17:41:52 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <xTE2qH2lnlJxT7UYzz_pH6FSaHQFQRB1RVZ8FNmRO_w=.12a9d246-7171-43b4-a4eb-977fdd146cfa@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Thanks for the reminder. The new alias is nice, easier to run all tier tests. I often run xml-only as well that includes jaxp_all plus a small set of jaxp tests in jdk_all (test/jdk/javax/xml/jaxp). But that's just me, jdk_all already covers those tests.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1827838226

From naoto at openjdk.org  Wed Jan 17 18:21:51 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Jan 2024 18:21:51 GMT
Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized'
 unnecessarily
In-Reply-To: <oeypt73pZ3oIF1BQU-Nnn8IO5Jb5kvZ4w5ngam36TBs=.a7141969-655c-41b4-8dca-94cca69d6662@github.com>
References: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
 <oeypt73pZ3oIF1BQU-Nnn8IO5Jb5kvZ4w5ngam36TBs=.a7141969-655c-41b4-8dca-94cca69d6662@github.com>
Message-ID: <Leses-SHKnelU4_Ma1Ak6YfbF1YxcQFpq8MwXQus6EY=.207285f8-db0b-43a9-a4c9-13241fa0c9c1@github.com>

On Tue, 16 Jan 2024 11:12:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily
>
> src/java.base/share/classes/java/util/TimeZone.java line 629:
> 
>> 627:      */
>> 628:     public static String[] getAvailableIDs(int rawOffset) {
>> 629:         return ZoneInfo.getAvailableIDs(rawOffset);
> 
> BTW can we call `ZoneInfoFile.getZoneIds` here directly? 
> `ZoneInfo.getAvailableIDs` bridge seems redudnant.

`TimeZone` is an abstract class, and `ZoneInfo` is an implementation. So to me, it is clearer to call the overriden method in the implementation even though the reason you mentioned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17441#discussion_r1456249396

From asemenyuk at openjdk.org  Wed Jan 17 18:39:00 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 17 Jan 2024 18:39:00 GMT
Subject: [jdk22] RFR: 8322799: Test JPKG003-013: ServiceTest fails because the
 user cannot uninstall the "servicetest" package on OEL 9.2 x64 and
 OEL 9.2 64-bit Arm (aarch64)
Message-ID: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>

Clean backport

-------------

Commit messages:
 - Backport 8e12053e0352a26ecd7f2b9bc298ddb8fb4bb61b

Changes: https://git.openjdk.org/jdk22/pull/88/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322799
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/88/head:pull/88

PR: https://git.openjdk.org/jdk22/pull/88

From asemenyuk at openjdk.org  Wed Jan 17 18:43:49 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 17 Jan 2024 18:43:49 GMT
Subject: [jdk22] RFR: 8322799: Test JPKG003-013: ServiceTest fails because
 the user cannot uninstall the "servicetest" package on OEL 9.2 x64
 and OEL 9.2 64-bit Arm (aarch64)
In-Reply-To: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>
References: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>
Message-ID: <E-5y5ZLCINrmObgHMcg2JM1t8jvmlQEFBQoIoNcB-XI=.0e2d8c9a-9b83-493a-8845-bd6bb40750ad@github.com>

On Wed, 17 Jan 2024 18:33:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean backport

@alexeysemenyukoracle please review

-------------

PR Comment: https://git.openjdk.org/jdk22/pull/88#issuecomment-1896427625

From viktor.klang at oracle.com  Wed Jan 17 19:48:07 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 17 Jan 2024 19:48:07 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/dfbb5a25/attachment.htm>

From forax at univ-mlv.fr  Wed Jan 17 19:49:07 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 17 Jan 2024 20:49:07 +0100 (CET)
Subject: Gatherer API : wildcards complaint
In-Reply-To: <MW4PR10MB5774510AC07F81FCE2AA7EEDFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <440278492.105063841.1705506935769.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774510AC07F81FCE2AA7EEDFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1373912389.105157231.1705520947512.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, January 17, 2024 5:49:01 PM
> Subject: Re: Gatherer API : wildcards complaint

> Hi R?mi,

> Thank you for the feedback?examples would be much appreciated!

Here is an example with an interface and a class, 

interface Counter { 
void increment (); 
int value (); 
} 

Gatherer < String , Counter , Integer > count () { 
class CounterImpl implements Counter { 
int counter ; 

@Override 
public void increment () { 
counter ++; 
} 

@Override 
public int value () { 
return counter ; 
} 
} 
Supplier < CounterImpl > initializer = CounterImpl :: new ; 
Gatherer . Integrator < Counter , String , Gatherer . Downstream <? super Integer >> integrator = ( counter , _ , _ ) -> { 
counter .increment(); 
return true ; 
}; 
BiConsumer < Counter , Gatherer . Downstream <? super Integer >> finisher = ( counter , downstream ) -> { 
downstream .push( counter .value()); 
}; 
return Gatherer . ofSequential ( initializer , integrator , finisher ); // does not compile :( 
} 

void main () { 
System . out .println( Stream . of ( "foo" ).gather(count()).findFirst().orElseThrow()); 
} 

if instead of explicitly typing each functions, we directly call ofSequential, it works 

return Gatherer . ofSequential ( 
CounterImpl :: new , 
( Counter counter , String _ , Gatherer . Downstream <? super Integer > _ ) -> { 
counter .increment(); 
return true ; 
}, 
( Counter counter , Gatherer . Downstream <? super Integer > downstream ) -> { 
downstream .push( counter .value()); 
} 
); 

because here, CounterImpl::new is inferred as Supplier<Counter>. 

> Cheers,
> ?

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
> <forax at univ-mlv.fr>
> Sent: Wednesday, 17 January 2024 16:55
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Gatherer API : wildcards complaint
> Hello,
> this is a minor complaint but I do not see a raison to not getting this right.

> Currently the Gatherer API does not use the wildcard correctly, which is not
> fully an issue because there is "enough" wildcards that if you rely on the
> inference, it will work.

> The problem is that when you write code, you make mistakes and usually when you
> have a typing issue, a way to debug it is to fix the type arguments
> de-activating the inference.
> But because there are some missing wildcards, this debugging strategy just fail
> flat with more typing errors.

> I think that fixing the missing wildcards will hep users (or a least me) to have
> a better experience when using the Gatherer API.

> I can help and propose a PR if you want.

> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/75d04e9e/attachment-0001.htm>

From viktor.klang at oracle.com  Wed Jan 17 20:00:32 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 17 Jan 2024 20:00:32 +0000
Subject: Gatherer API : wildcards complaint
In-Reply-To: <1373912389.105157231.1705520947512.JavaMail.zimbra@univ-eiffel.fr>
References: <440278492.105063841.1705506935769.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774510AC07F81FCE2AA7EEDFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1373912389.105157231.1705520947512.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774DE2F0C6C198219EF787BFF722@MW4PR10MB5774.namprd10.prod.outlook.com>

Ah, now I see what you mean! Thank you ?

The reason for the signature of `Gatherer.of` was to mirror as much as possible of `Collector.of`[1] so I would argue that if we tweak the variance of one then we should consider tweaking it for both.

1:https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Collector.java#L264

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 20:49
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: [External] : Re: Gatherer API : wildcards complaint



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 5:49:01 PM
Subject: Re: Gatherer API : wildcards complaint
Hi R?mi,

Thank you for the feedback?examples would be much appreciated!

Here is an example with an interface and a class,


interface Counter {
  void increment();
  int value();
}

Gatherer<String, Counter, Integer> count() {
  class CounterImpl implements Counter {
    int counter;

    @Override
    public void increment() {
      counter++;
    }

    @Override
    public int value() {
      return counter;
    }
  }
  Supplier<CounterImpl> initializer = CounterImpl::new;
  Gatherer.Integrator<Counter, String, Gatherer.Downstream<? super Integer>> integrator = (counter, _, _) -> {
    counter.increment();
    return true;
  };
  BiConsumer<Counter, Gatherer.Downstream<? super Integer>> finisher = (counter, downstream) -> {
    downstream.push(counter.value());
  };
  return Gatherer.ofSequential(initializer, integrator, finisher);    // does not compile :(
}

void main() {
  System.out.println(Stream.of("foo").gather(count()).findFirst().orElseThrow());
}

if instead of explicitly typing each functions, we directly call ofSequential, it works


return Gatherer.ofSequential(
    CounterImpl::new,
    (Counter counter, String _, Gatherer.Downstream<? super Integer> _) -> {
      counter.increment();
      return true;
    },
    (Counter counter, Gatherer.Downstream<? super Integer> downstream) -> {
      downstream.push(counter.value());
    }
);

because here, CounterImpl::new is inferred as Supplier<Counter>.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:55
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer API : wildcards complaint

Hello,
this is a minor complaint but I do not see a raison to not getting this right.

Currently the Gatherer API does not use the wildcard correctly, which is not fully an issue because there is "enough" wildcards that if you rely on the inference, it will work.

The problem is that when you write code, you make mistakes and usually when you have a typing issue, a way to debug it is to fix the type arguments de-activating the inference.
But because there are some missing wildcards, this debugging strategy just fail flat with more typing errors.

I think that fixing the missing wildcards will hep users (or a least me) to have a better experience when using the Gatherer API.

I can help and propose a PR if you want.

regards,
R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/6f2f80b8/attachment-0001.htm>

From jlaskey at openjdk.org  Wed Jan 17 20:04:58 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 17 Jan 2024 20:04:58 GMT
Subject: [jdk22] Integrated: 8322512: StringBuffer.repeat does not work
 correctly after toString() was called
In-Reply-To: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
References: <ePavkc3u2Hw_rTBihFcz-1pgDr4d4wyW1H8MSjdsWAQ=.6371954f-8e29-45f2-8b21-25abacc2987d@github.com>
Message-ID: <w6QZxM7rL9ohSYVMgEz6yT2lyW-gTNuh0BJ2hBA7I5Q=.7f6527c9-6690-4371-bc10-9cebea253b87@github.com>

On Wed, 17 Jan 2024 14:21:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The new repeat methods were not clearing the toStringCache.

This pull request has now been integrated.

Changeset: 60c68a13
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/60c68a13639fe79cc2510d551b8c1c7d7e1a02f3
Stats:     16 lines in 2 files changed: 15 ins; 0 del; 1 mod

8322512: StringBuffer.repeat does not work correctly after toString() was called

Reviewed-by: prappo, redestad
Backport-of: df22fb322e6c4c9931a770bd0abf4c43b83c4e4a

-------------

PR: https://git.openjdk.org/jdk22/pull/87

From forax at univ-mlv.fr  Wed Jan 17 20:16:41 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 17 Jan 2024 21:16:41 +0100 (CET)
Subject: Seing a Collector as a Gatherer
In-Reply-To: <MW4PR10MB5774515940B3D52888E28383FF722@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <485039120.105074388.1705507680624.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774515940B3D52888E28383FF722@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <563231281.105174574.1705522601249.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Sent: Wednesday, January 17, 2024 6:01:38 PM
> Subject: Re: Seing a Collector as a Gatherer

> Hi R?mi,

> Yes, this was something I was hoping to get into the preview, but I wasn't sure
> where that conversion should end up.

> There are a few different places where it might go:

> Gatherer.of(Collector)
> Gatherers.collect(Collector)
> Collector.asGatherer()
> Collectors.gather(Collector)

> I wasn't really convinced where it should go, and I was hesitant to making any
> changes to existing public interfaces as a "nice to have", so I opted to leave
> it out for now.

> I think people would prefer to see it on Collector as a default method, but as I
> said before, making changes to Collector wasn't something I was ready to
> prioritize for the (first) JEP.

I think this method is also important pedagogically, there should be a place that describe the relationship between a Collector and a Gatherer. 

For Gatherer.of(), this one seems alien compared to the other overloads of of()/ofSequential() and to a lesser extend I do not like too much to have overloads with one parameter with two different interfaces, because someone can comes with a class that implements both Collector and Integrator (as stupid as it is), 

For Gatherers.collect(Collector) is fine, 

For Collector.asGatherer(), a default method has the disadvantage that usually a Collector is typed from left to right so calling an instance method requires an intermediary variable 
Collector<String, ?, List<String>> collector = Collector.toList(); // ok 
Gatherer<String, ?, List<String>> gatherer = Collector.toList().asGatherer(); // we are in trouble here 
that's why Collectors.collectingAndThen() (aka compose the finisher) is a static method in Collectors and not an instance method in Collector (finishAndThen ?), 

For Collectors.gather(), methods inside Collectors tend to return a Collector. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
> <forax at univ-mlv.fr>
> Sent: Wednesday, 17 January 2024 17:08
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Seing a Collector as a Gatherer
> Hello,
> I may have overlook that, but it seems there is no method to see a Collector as
> a Gatherer.

> A Gatherer is more general than a Collector and a Gatherer with a greedy
> integrator that does not call Downstream.push in the intergator and only once
> is the finisher is basicaly a Collector.

> In code:
> <E, A, T> Gatherer<E, A, T> asGatherer(Collector<? super E, A, ? extends T>
> collector) {
> var supplier = collector.supplier();
> var accumulator = collector.accumulator();
> var combiner = collector.combiner();
> var finisher = collector.finisher();
> return Gatherer.of(supplier,
> Gatherer.Integrator.ofGreedy((state, element, _) -> {
> accumulator.accept(state, element);
> return true;
> }),
> combiner,
> (state, downstream) -> downstream.push(finisher.apply(state)));
> }

> This is eaxctly how Gatherer.fold() works.

> Is there a reason why such method does not exist ?

> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240117/e155a8ed/attachment.htm>

From mchung at openjdk.org  Wed Jan 17 20:56:13 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 17 Jan 2024 20:56:13 GMT
Subject: RFR: 8159927: Add a test to verify JMOD files created in the images do
 not have debug symbols
Message-ID: <grMfpKA3RUlxO8UhrNIfsbydCJ_UvJL-I9Dlt7OgccQ=.2ecff3bc-66f5-40e3-8b20-8f9978ef4258@github.com>

The build excludes the native debug symbols in JMOD files created for JDK modules (see make/CreateJmods.gmk).   This PR adds a test to verify that native debug symbols are excluded as expected.

-------------

Commit messages:
 - 8159927: Add a test to verify JMOD files created in the images do not have debug symbols

Changes: https://git.openjdk.org/jdk/pull/17467/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8159927
  Stats: 76 lines in 1 file changed: 76 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17467/head:pull/17467

PR: https://git.openjdk.org/jdk/pull/17467

From almatvee at openjdk.org  Wed Jan 17 21:03:54 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 17 Jan 2024 21:03:54 GMT
Subject: [jdk22] RFR: 8322799: Test JPKG003-013: ServiceTest fails because
 the user cannot uninstall the "servicetest" package on OEL 9.2 x64
 and OEL 9.2 64-bit Arm (aarch64)
In-Reply-To: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>
References: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>
Message-ID: <yDi3koVhPY_bTbbFO2D4WBAYZpUcN9uaFy4PIWFoZ7M=.26707ba4-7cb8-4d4f-8e65-d537a30de479@github.com>

On Wed, 17 Jan 2024 18:33:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean backport

Looks good. I verified that it is a clean backport.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/88#pullrequestreview-1828180526

From duke at openjdk.org  Wed Jan 17 21:16:02 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 17 Jan 2024 21:16:02 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v3]
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@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%.
> 
> ### JMH results for testPutAll (size = 10000)
> 
> before patch:
> 
> 
> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>   4315291.542 ?(99.9%) 336034.190 ns/op [Average]
>   (min, avg, max) = (3974688.194, 4315291.542, 4871772.209), stdev = 314326.589
>   CI (99.9%): [3979257.352, 4651325.731] (assumes normal distribution)
> 
> 
> after patch:
> 
> 
> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>   3006955.723 ?(99.9%) 271757.969 ns/op [Average]
>   (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev = 254202.573
>   CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
> 
> 
> Average time is decreased about 30%.

Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:

  putAll presize based on sum on both map sizes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17116/files
  - new: https://git.openjdk.org/jdk/pull/17116/files/3632649c..3efa593d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17116&range=01-02

  Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 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 duke at openjdk.org  Wed Jan 17 21:16:03 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 17 Jan 2024 21:16:03 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not
 transfer from old table on presizing [v2]
In-Reply-To: <16gxaKYHEH5R2fmIJmlPldL8c7LHxAiRV2mMnxGE2ZY=.44794184-2ae8-4554-a1db-4e1e1484dd08@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <JMbIMgzgS79yabXSbG9Klzi4htgWQWitoevKVuIlyD0=.8d3056a9-f53a-4b84-862a-69530706d797@github.com>
 <EX6MUuHXifkbTyriqXA9OGIc6n2O1MJZwcRsv_LiiwU=.fbb6d936-1755-41eb-af45-5da6ce6e0247@github.com>
 <AmlJOs7hkqD5rZCH-zPQzEaZOWNmg7VQS2TIJkDEbig=.be56cd27-bebe-49c2-8092-e6b98989daf0@github.com>
 <tGw8-oOblGEriLtfGjyx3NWJoEUGX9U5BCNn3Qyq78U=.01a8ff07-6ee0-4e37-aeaf-cf34685401dc@github.com>
 <n46ErejQL-fRok3eBRhr_fhwaw3aKmgi1GOOh1l4u1g=.e4292d14-590c-4d45-a747-04dfb6d42e76@github.com>
 <16gxaKYHEH5R2fmIJmlPldL8c7LHxAiRV2mMnxGE2ZY=.44794184-2ae8-4554-a1db-4e1e1484dd08@github.com>
Message-ID: <6APClpqSlW7QfZU-eW_FgW3TlII0NQQZXJHpK6fpQDE=.2fb89cf8-e82d-4ad4-a4a9-38fbfa41f578@github.com>

On Fri, 12 Jan 2024 08:51:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>>> tryPresize(int size) is doing and if its size argument is supposed to contain the additional number of elements which will be inserted into the hash map or if it is a hint for the new total size of the hash map
>> 
>> Argument `size` for `tryPresize()` is a hint for the **new total size** of the hash map. If the size is too small compared to the current size of the map, there will be no resizing.
>
> Thanks. In that case, calling `tryPresize()` with `size < this.size()` doesn't make sense and we should call it with `this.size() + m.size()`.

Thanks. Just committed this change. Also added a new benchmark for `putAll()` and the results in the top post.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1456490539

From clanger at openjdk.org  Wed Jan 17 21:20:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 Jan 2024 21:20:55 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
Message-ID: <IpZsBIdCsYnlx43wcJFRVH7tzHX7cIjeGH6hHrX3Cnk=.4cdba3d0-198f-4ef2-a8af-6cbec6b9a0d9@github.com>

On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

I guess you should credit SAP here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1456496044

From prappo at openjdk.org  Wed Jan 17 21:26:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Jan 2024 21:26:02 GMT
Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base
Message-ID: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>

Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/17468/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17468&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324053
  Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17468/head:pull/17468

PR: https://git.openjdk.org/jdk/pull/17468

From acobbs at openjdk.org  Wed Jan 17 21:31:22 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Jan 2024 21:31:22 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v2]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Quote '{' and '}' in subformat patterns, but only it not already quoted.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/688f5748..a9d78c76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=00-01

  Stats: 344 lines in 4 files changed: 300 ins; 18 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From acobbs at openjdk.org  Wed Jan 17 21:34:49 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Jan 2024 21:34:49 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern
In-Reply-To: <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
Message-ID: <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>

On Tue, 16 Jan 2024 22:05:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Hi Archie, thanks for the proposed fix. I am still taking a look, but I wanted to demonstrate a current issue,
> 
> (Jshell with your patch)
> 
> 
> var pattIn = "Test: {0,number,foo'{'#.00}";
> MessageFormat mFmt = new MessageFormat(pattIn);
> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo{#.00}";
> 
> 
> 
> var pattIn = "Test: {0,number,foo'}'#.00}";
> MessageFormat mFmt = new MessageFormat(pattIn);
> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo'}'#.00}";
> 
> 
> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted. 
> 
> Also in response to your earlier question on core-libs-dev, ideally invoking toPattern() can roundtrip, but there are known issues, such as a custom user defined Format subclass, or one of the newer Format subclasses that do not implement the toPattern() method. I am working on making this apparent in the specification of the method in a separate issue.

Hi @justin-curtis-lu,

Thanks a lot for taking a look, I am glad for any other set of eyes on this tricky stuff!

> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted.

You're right - the problem exists with both `{` and `}`, as is shown here (unmodified jshell):


$ jshell
|  Welcome to JShell -- Version 17.0.9
|  For an introduction type: /help intro

jshell> import java.text.*;

jshell> new MessageFormat("Test: {0,number,foo'{'#.00}");
$2 ==> java.text.MessageFormat at 951c5b58

jshell> $2.toPattern()
$3 ==> "Test: {0,number,foo{#.00}"

jshell> new MessageFormat($3)
|  Exception java.lang.IllegalArgumentException: Unmatched braces in the pattern.
|        at MessageFormat.applyPattern (MessageFormat.java:521)
|        at MessageFormat.<init> (MessageFormat.java:371)
|        at (#4:1)


I've been missing the forest for the trees a bit and I think the fix can be simpler now.

For the record, here is my latest understanding of what's going on...

1. When `MessageFormat.toPattern()` constructs the combined pattern string, it concatenates the plain text bits, suitably escaped, and the pattern strings from each subformat.
1. The subformat strings are already escaped, in the sense that you can take (for example) a `ChoiceFormat` format string and use it as-is to recreate that same `ChoiceFormat`, but they are escaped _only for their own purposes_.
1. The original example is an example of where this matters - `ChoiceFormat` needs to escape `#`, `|`, etc., but doesn't need to escape `{` or `}` - but a `MessageFormat` format string does need to escape those.
1. Therefore, the correct fix is for `MessageFormat.toPattern()` to modify the subformat strings by quoting any _unquoted_ `{` or `}` characters while leaving any already-quoted characters alone.

Updated in a9d78c76f5f. I've also updated the test so it does more thorough round-trip checks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1896840300

From prappo at openjdk.org  Wed Jan 17 21:36:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Jan 2024 21:36:52 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue) [v4]
In-Reply-To: <DCVF-CY868Tn0W_W4gcn1IPQS8MwXYSmtNwf5y6oMDA=.8b1c1264-4fa1-4d41-ba92-c11d7a143934@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
 <DCVF-CY868Tn0W_W4gcn1IPQS8MwXYSmtNwf5y6oMDA=.8b1c1264-4fa1-4d41-ba92-c11d7a143934@github.com>
Message-ID: <1Hue900RygG0lCLlE6eUcGb8LyeUbgl-ByIEAsjsHDU=.c796471f-603c-457a-a8e4-3936e0c0a6b3@github.com>

On Tue, 2 Jan 2024 14:37:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8311864
>  - Merge remote-tracking branch 'jdk/master' into 8311864
>  - Merge branch 'master' into 8311864
>  - Initial commit

To Skara bots: keep this PR alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1896855868

From naoto at openjdk.org  Wed Jan 17 22:59:51 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Jan 2024 22:59:51 GMT
Subject: RFR: 8324053: Use the blessed modifier order for sealed in
 java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <lzDahkWuw2qH2LnWcPQK5yU5GDyLU6-S5Cqh6-gmQ2w=.fb2fb144-f9bb-4097-b375-7f2592132ab6@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1828357538

From asemenyuk at openjdk.org  Wed Jan 17 23:08:56 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 17 Jan 2024 23:08:56 GMT
Subject: [jdk22] Integrated: 8322799: Test JPKG003-013: ServiceTest fails
 because the user cannot uninstall the "servicetest" package on OEL 9.2 x64 and
 OEL 9.2 64-bit Arm (aarch64)
In-Reply-To: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>
References: <byArkATpf8RNyTIfdpBDQ9NngCzWf1a_PBKX8agMu4M=.ba236cb9-26ff-4902-a809-17af1e6c39d0@github.com>
Message-ID: <nzut5OrMM9Xf0NvZDrq48D94lOpiF4RkYKKDVRemYW8=.20d3ed42-1255-4000-aa4a-f96d121e2d39@github.com>

On Wed, 17 Jan 2024 18:33:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: b5ed8cca
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b5ed8cca77ab3d4303dde691d6ccb113f3ce0a65
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8322799: Test JPKG003-013: ServiceTest fails because the user cannot uninstall the "servicetest" package on OEL 9.2 x64 and OEL 9.2 64-bit Arm (aarch64)

Reviewed-by: almatvee
Backport-of: 8e12053e0352a26ecd7f2b9bc298ddb8fb4bb61b

-------------

PR: https://git.openjdk.org/jdk22/pull/88

From darcy at openjdk.org  Wed Jan 17 23:12:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Jan 2024 23:12:49 GMT
Subject: RFR: 8324053: Use the blessed modifier order for sealed in
 java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <FweRScYClF7i3NykFaDuBAgRcplKO6ENt4H3fuc3CcE=.9ccfeb5f-9a33-4863-8096-9927172df80c@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1828378857

From dcubed at openjdk.org  Thu Jan 18 01:07:14 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 01:07:14 GMT
Subject: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not
 need a core file
Message-ID: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>

A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

-------------

Commit messages:
 - 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

Changes: https://git.openjdk.org/jdk/pull/17476/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321938
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17476/head:pull/17476

PR: https://git.openjdk.org/jdk/pull/17476

From duke at openjdk.org  Thu Jan 18 05:35:20 2024
From: duke at openjdk.org (jmehrens)
Date: Thu, 18 Jan 2024 05:35:20 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v3]
In-Reply-To: <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
Message-ID: <453O0eMb98HWkQb2yUY95T43KnSs9eBUY-f9EabFXwU=.44cdc1f9-251a-4c53-bc6e-9ddba84bd42e@github.com>

On Wed, 17 Jan 2024 21:16:02 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> 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%.
>> 
>> ### JMH results for testPutAll (size = 10000)
>> 
>> before patch:
>> 
>> 
>> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>>   4315291.542 ?(99.9%) 336034.190 ns/op [Average]
>>   (min, avg, max) = (3974688.194, 4315291.542, 4871772.209), stdev = 314326.589
>>   CI (99.9%): [3979257.352, 4651325.731] (assumes normal distribution)
>> 
>> 
>> after patch:
>> 
>> 
>> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>>   3006955.723 ?(99.9%) 271757.969 ns/op [Average]
>>   (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev = 254202.573
>>   CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
>> 
>> 
>> Average time is decreased about 30%.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   putAll presize based on sum on both map sizes

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1088:

> 1086:     public void putAll(Map<? extends K, ? extends V> m) {
> 1087:         if (table != null) {
> 1088:             tryPresize(size() + m.size());

Is overflow not an issue here because calling tryPresize with a negative value will invoke tableSizeFor?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1456919954

From duke at openjdk.org  Thu Jan 18 07:20:15 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 18 Jan 2024 07:20:15 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v3]
In-Reply-To: <453O0eMb98HWkQb2yUY95T43KnSs9eBUY-f9EabFXwU=.44cdc1f9-251a-4c53-bc6e-9ddba84bd42e@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
 <453O0eMb98HWkQb2yUY95T43KnSs9eBUY-f9EabFXwU=.44cdc1f9-251a-4c53-bc6e-9ddba84bd42e@github.com>
Message-ID: <mN__lEll2Wdwg-Xvqnhwbf3Zemi459wCsYtp6vyOsb4=.a450e1d5-63c3-472e-bfd0-82665245e309@github.com>

On Thu, 18 Jan 2024 05:32:26 GMT, jmehrens <duke at openjdk.org> wrote:

>> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   putAll presize based on sum on both map sizes
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1088:
> 
>> 1086:     public void putAll(Map<? extends K, ? extends V> m) {
>> 1087:         if (table != null) {
>> 1088:             tryPresize(size() + m.size());
> 
> Is overflow not an issue here because calling tryPresize with a negative value will invoke tableSizeFor?

When?`tableSizeFor` is?called with?a?negative?value greater?than?`Integer.MIN_VALUE`, it?ll just?return?`+1`:
https://github.com/openjdk/jdk/blob/ff8cc268fdaaf85299c94088a226b73e7eaf6bdb/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L704-L707

This?will in?turn cause?`tryPresize` to?do?nothing when?`table` is?already?initialized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1457023596

From dholmes at openjdk.org  Thu Jan 18 07:50:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Jan 2024 07:50:13 GMT
Subject: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does
 not need a core file
In-Reply-To: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
References: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
Message-ID: <Ucl2isqJKXPR0CEk-axaV2bg-dJWW6MJAvnOZrtTtpY=.4eee1321-3a80-4ea8-b060-5116153c0814@github.com>

On Thu, 18 Jan 2024 00:58:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

Good and trivial.

Copyright year needs updating.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17476#pullrequestreview-1829051168

From dholmes at openjdk.org  Thu Jan 18 08:05:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Jan 2024 08:05:15 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
Message-ID: <dxBcuBLhFh50qFsePFEXYzVeOh6aM3qsDbjf4Ey96cs=.e7c0c4e8-528b-4008-b548-400763a4c29d@github.com>

On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

src/java.base/share/classes/java/lang/Thread.java line 1709:

> 1707:         // Setting the interrupt status must be done before reading nioBlocker.
> 1708:         interrupted = true;
> 1709:         interrupt0();  // inform VM of interrupt

It is really safe/correct to move this outside the synchronized block? I know things have changed a bit with loom but we've "always" held a lock when doing the actual interrupt. I'd have to check the VM logic to be sure it can be called concurrently from multiple threads for the same target thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1457061745

From rrich at openjdk.org  Thu Jan 18 08:18:17 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 18 Jan 2024 08:18:17 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <IpZsBIdCsYnlx43wcJFRVH7tzHX7cIjeGH6hHrX3Cnk=.4cdba3d0-198f-4ef2-a8af-6cbec6b9a0d9@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <IpZsBIdCsYnlx43wcJFRVH7tzHX7cIjeGH6hHrX3Cnk=.4cdba3d0-198f-4ef2-a8af-6cbec6b9a0d9@github.com>
Message-ID: <S1frK1GwNrBZ9L61cLZtl6tlNQVRmxl3TLbFqPDSn9o=.3e77e505-8166-450f-aaff-aa3caa3a3ba4@github.com>

On Wed, 17 Jan 2024 21:18:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Alan
>
> test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> I guess you should credit SAP here.

Alan wrote the test. I added him as contributor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1457074572

From alanb at openjdk.org  Thu Jan 18 08:35:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Jan 2024 08:35:15 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <dxBcuBLhFh50qFsePFEXYzVeOh6aM3qsDbjf4Ey96cs=.e7c0c4e8-528b-4008-b548-400763a4c29d@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <dxBcuBLhFh50qFsePFEXYzVeOh6aM3qsDbjf4Ey96cs=.e7c0c4e8-528b-4008-b548-400763a4c29d@github.com>
Message-ID: <euHlol2zVrwTTS5SzpQK9qeLTXYXK7daM0Ah3BijnOA=.26dbf1c9-8886-4b49-aa80-1f4b2a595592@github.com>

On Thu, 18 Jan 2024 08:02:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It is really safe/correct to move this outside the synchronized block? I know things have changed a bit with loom but we've "always" held a lock when doing the actual interrupt. I'd have to check the VM logic to be sure it can be called concurrently from multiple threads for the same target thread.

This hasn't changed. The interruptLock is used to coordinate the add/remove of the nioBlocker. When there is no nioBlocker set then the interrupt status and unparking (as in JavaThread::interrupt) executes without the interruptLock.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1457092058

From viktor.klang at oracle.com  Thu Jan 18 09:11:31 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 18 Jan 2024 09:11:31 +0000
Subject: Seing a Collector as a Gatherer
In-Reply-To: <563231281.105174574.1705522601249.JavaMail.zimbra@univ-eiffel.fr>
References: <485039120.105074388.1705507680624.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774515940B3D52888E28383FF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <563231281.105174574.1705522601249.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774613BEBF7E32AB1ABADDBFF712@MW4PR10MB5774.namprd10.prod.outlook.com>

Yes, having the conversion in Gatherers would seem like the most sensible option.

Then the question becomes whether gather is the most sensible name for it?I'm thinking of readability under the use of static imports etc. gatherUsing(), viaCollector(), adapt(), etc.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 21:16
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: [External] : Re: Seing a Collector as a Gatherer



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Sent: Wednesday, January 17, 2024 6:01:38 PM
Subject: Re: Seing a Collector as a Gatherer
Hi R?mi,

Yes, this was something I was hoping to get into the preview, but I wasn't sure where that conversion should end up.

There are a few different places where it might go:

Gatherer.of(Collector)
Gatherers.collect(Collector)
Collector.asGatherer()
Collectors.gather(Collector)

I wasn't really convinced where it should go, and I was hesitant to making any changes to existing public interfaces as a "nice to have", so I opted to leave it out for now.

I think people would prefer to see it on Collector as a default method, but as I said before, making changes to Collector wasn't something I was ready to prioritize for the (first) JEP.

I think this method is also important pedagogically, there should be a place that describe the relationship between a Collector and a Gatherer.

For Gatherer.of(), this one seems alien compared to the other overloads of of()/ofSequential() and to a lesser extend I do not like too much to have overloads with one parameter with two different interfaces, because someone can comes with a class that implements both Collector and Integrator (as stupid as it is),

For Gatherers.collect(Collector) is fine,

For Collector.asGatherer(), a default method has the disadvantage that usually a Collector is typed from left to right so calling an instance method requires an intermediary variable
    Collector<String, ?, List<String>> collector = Collector.toList();  // ok
    Gatherer<String, ?, List<String>> gatherer = Collector.toList().asGatherer();  // we are in trouble here
 that's why Collectors.collectingAndThen() (aka compose the finisher) is a static method in Collectors and not an instance method in Collector (finishAndThen ?),

For Collectors.gather(), methods inside Collectors tend to return a Collector.




Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 17:08
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Seing a Collector as a Gatherer

Hello,
I may have overlook that, but it seems there is no method to see a Collector as a Gatherer.

A Gatherer is more general than a Collector and a Gatherer with a greedy integrator that does not call Downstream.push in the intergator and only once is the finisher is basicaly a Collector.

In code:
<E, A, T> Gatherer<E, A, T> asGatherer(Collector<? super E, A, ? extends T> collector) {
  var supplier = collector.supplier();
  var accumulator = collector.accumulator();
  var combiner = collector.combiner();
  var finisher = collector.finisher();
  return Gatherer.of(supplier,
      Gatherer.Integrator.ofGreedy((state, element, _) -> {
        accumulator.accept(state, element);
        return true;
      }),
      combiner,
      (state, downstream) -> downstream.push(finisher.apply(state)));
}

This is eaxctly how Gatherer.fold() works.

Is there a reason why such method does not exist ?

regards,
R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/8f23697d/attachment-0001.htm>

From rrich at openjdk.org  Thu Jan 18 09:24:16 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 18 Jan 2024 09:24:16 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <euHlol2zVrwTTS5SzpQK9qeLTXYXK7daM0Ah3BijnOA=.26dbf1c9-8886-4b49-aa80-1f4b2a595592@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <dxBcuBLhFh50qFsePFEXYzVeOh6aM3qsDbjf4Ey96cs=.e7c0c4e8-528b-4008-b548-400763a4c29d@github.com>
 <euHlol2zVrwTTS5SzpQK9qeLTXYXK7daM0Ah3BijnOA=.26dbf1c9-8886-4b49-aa80-1f4b2a595592@github.com>
Message-ID: <QPfyDe4CjN99Z753dMkklMRksH7QWQAdZFzZDcouJq4=.b37bd9c7-f640-4976-ad17-8029a26f7fb5@github.com>

On Thu, 18 Jan 2024 08:32:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1709:
>> 
>>> 1707:         // Setting the interrupt status must be done before reading nioBlocker.
>>> 1708:         interrupted = true;
>>> 1709:         interrupt0();  // inform VM of interrupt
>> 
>> It is really safe/correct to move this outside the synchronized block? I know things have changed a bit with loom but we've "always" held a lock when doing the actual interrupt. I'd have to check the VM logic to be sure it can be called concurrently from multiple threads for the same target thread.
>
>> It is really safe/correct to move this outside the synchronized block? I know things have changed a bit with loom but we've "always" held a lock when doing the actual interrupt. I'd have to check the VM logic to be sure it can be called concurrently from multiple threads for the same target thread.
> 
> This hasn't changed. The interruptLock is used to coordinate the add/remove of the nioBlocker. When there is no nioBlocker set then the interrupt status and unparking (as in JavaThread::interrupt) has always executesd without the interruptLock.

I think that interrupting is just asynchronous to some extent.
E.g. a thread polls its interrupt status clearing it thereby (without lock) before calling nio. A concurrent interrupt can be lost then even if the lock is acquired.
(Maybe clearing should not be done by a public method)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1457152809

From forax at univ-mlv.fr  Thu Jan 18 09:28:27 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 18 Jan 2024 10:28:27 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, January 17, 2024 8:48:07 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> Hi R?mi,

> You can find some of my benches here: [
> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
> |
> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
> ]

> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
> didn't end up worth it when looking at the bench results over a wide array of
> stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED, 
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized. 

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT. 

[CC Paul, so he can correct me if i'm saying something stupid] 

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams. 
First, the JIT has two ways to profile types at runtime, 
Either a method takes a function as parameter 
void map(Function function) { 
function.apply(...) 
} 
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined, 
Or a method use a field 
class Op { 
Function function; 

void map() { 
function.apply(...) 
} 
} 
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize. 

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter. 

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream. 

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
> <forax at univ-mlv.fr>
> Sent: Wednesday, 17 January 2024 16:48
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Gatherer: spliterator characteristics are not propagated
> While doing some benchmarking of the Gatherer API, i've found that the
> characteristics of the spliterator was not propagated by the method
> Stream.gather() making the stream slower than it should.

> As an example, there is no way when reimplementing map() using a Gatherer to say
> that this intermediate operation keep the size, which is important if the
> terminal operation is toList() because if the size is known, toList() will
> presize the List and avoid the creation of an intermediary ArrayList.

> See [
> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
> |
> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
> ]

> I think that adding a way to propagate the spliterator characteristics through a
> Gatherer would greatly improve the performance of commons streams (at least all
> the ones that end with a call to toList).

> I have some idea of how to do that, but I prefer first to hear if i've overlook
> something and if improving the performance is something worth changing the API.

> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/33a59f4b/attachment-0001.htm>

From JohannesS at lucanet.com  Thu Jan 18 09:30:25 2024
From: JohannesS at lucanet.com (Johannes Spangenberg)
Date: Thu, 18 Jan 2024 09:30:25 +0000
Subject: Avoiding Side Effects of ForkJoinPool.managedBlock
Message-ID: <BEZP281MB3105275CDD47FC9D544EB1A6B8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>

Hello,

I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change the behavior of the code. These changes in behavior have resulted in non-deterministic test failures in one of the repositories I work on. JUnit uses a ForkJoinPool when you enable parallel test execution. I would like to disable or avoid the side effects of various methods if called from a ForkJoinPool. So far, I haven't found a solution, except for completely replacing the use of the ForkJoinPool in JUnit with some custom scheduler which is not a ForkJoinPool.

Is there a solution to force an "unmanaged" block (as opposed to ForkJoinPool.managedBlock)? Is there alternatively a good approach to transfer CPU bound subtasks to another thread pool while blocking the ForkJoinWorkerThread without compensation? I have implemented a workaround which I explain below, but I am not sure if this will remain effective in future JDK versions. I am currently using JDK 17 but were also able to reproduce the issues with JDK 21.

I have observed the following side-effects caused by managed blocks or similar mechanisms:

1. Parallel stream methods execute another task (i.e. JUnit test) from the pool recursively, which is particularly problematic if your code utilizes any ThreadLocal.

2. Blocking methods spawn around 256 threads in total to "compensate" for the blocking operation. Consequently, you end up with up to 256 tests running concurrently, each of them might or might not be CPU bound (unknown to the ForkJoinPool).

3. Blocking methods may throw a RejectedExecutionException when the thread limit is reached. This is effectively a race condition which may lead to exceptions.

I have not been able to determine under which circumstances each behavior occurs. I am unaware of any thorough documentation that clearly outlines the expected behavior in different scenarios with different blocking methods. While (1.) and (3.) have caused test failures, (2.) simply causes JUnit to run 256 tests in parallel instead of the intended 12. I attached a JUnit test to reproduce (1.) and (3.), but it might not fail on every run.

Many of the blocking methods of the standard library include a check if the current thread is an instance of ForkJoinWorkerThread. My current workaround involves wrapping the code that makes blocking calls into a FutureTask which is executed on another thread and then joining this task afterwards. As of now, FutureTask.get() seems not to implement any of the side-effects. As the missing instanceof-check in FutureTask makes it inconsistent with other Futures like CompletableFuture, I fear it might be considered a "bug". I would like to know a safe solution which is specified to continue to work in future JDKs.

PS: There is also a ticket on the JUnit project about this topic, but it only talks about side-effect (2.), but not the other side-effects we observed.
https://github.com/junit-team/junit5/issues/3108

Thanks,
Johannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ForkJoinPoolTest.java
Type: application/octet-stream
Size: 1994 bytes
Desc: ForkJoinPoolTest.java
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/de997cb5/ForkJoinPoolTest-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7798 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/de997cb5/smime-0001.p7s>

From ihse at openjdk.org  Thu Jan 18 09:32:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Jan 2024 09:32:15 GMT
Subject: RFR: 8324053: Use the blessed modifier order for sealed in
 java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <sYBKbndDd3hJqkOldbE9Lwuv1kvfPx-pX-RjVtvQ6G4=.102dc24f-19c7-4241-a0b7-aaff20769422@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

Thanks! When this has been integrated, I can take a shot at the missorted `default`s.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1829238473

From dfuchs at openjdk.org  Thu Jan 18 09:49:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Jan 2024 09:49:13 GMT
Subject: RFR: 8324053: Use the blessed modifier order for sealed in
 java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <_1D6S_orn-H9wHL41PEskm8JN2PLJs_GvkxIg-Ht0Zs=.b3db368a-ee61-4951-b143-f49fb9e1f702@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1829273407

From prappo at openjdk.org  Thu Jan 18 10:04:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 18 Jan 2024 10:04:14 GMT
Subject: RFR: 8324053: Use the blessed modifier order for sealed in
 java.base
In-Reply-To: <sYBKbndDd3hJqkOldbE9Lwuv1kvfPx-pX-RjVtvQ6G4=.102dc24f-19c7-4241-a0b7-aaff20769422@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
 <sYBKbndDd3hJqkOldbE9Lwuv1kvfPx-pX-RjVtvQ6G4=.102dc24f-19c7-4241-a0b7-aaff20769422@github.com>
Message-ID: <VCIhSACSD78SXKxl1NOLDGeRiRNiuKEARWiTGbhpy_8=.3ed7434b-7469-4e15-92c8-792c98819cb5@github.com>

On Thu, 18 Jan 2024 09:29:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Thanks! When this has been integrated, I can take a shot at the missorted `default`s.

Thanks, I could've done that myself, but decided not to. You see, `default` should ideally be a [sole] modifier on a method: all other modifiers of a `default` method should be deleted. I'm not sure that reaching such an ideal would be welcomed.

Whatever you decide to do, be prepared to work manually. `bin/blessed-modifier-order.sh` is simple and robust but not specific. You'll have to carefully sift through other missortings it finds.

[sole]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117398.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17468#issuecomment-1898162068

From Alan.Bateman at oracle.com  Thu Jan 18 10:34:44 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Jan 2024 10:34:44 +0000
Subject: Avoiding Side Effects of ForkJoinPool.managedBlock
In-Reply-To: <BEZP281MB3105275CDD47FC9D544EB1A6B8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>
References: <BEZP281MB3105275CDD47FC9D544EB1A6B8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>
Message-ID: <e552b89e-b8d3-4242-b3af-64247cbf4e65@oracle.com>

On 18/01/2024 09:30, Johannes Spangenberg wrote:
> Hello,
>
> I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change the behavior of the code. These changes in behavior have resulted in non-deterministic test failures in one of the repositories I work on. JUnit uses a ForkJoinPool when you enable parallel test execution. I would like to disable or avoid the side effects of various methods if called from a ForkJoinPool. So far, I haven't found a solution, except for completely replacing the use of the ForkJoinPool in JUnit with some custom scheduler which is not a ForkJoinPool.
>
> Is there a solution to force an "unmanaged" block (as opposed to ForkJoinPool.managedBlock)? Is there alternatively a good approach to transfer CPU bound subtasks to another thread pool while blocking the ForkJoinWorkerThread without compensation? I have implemented a workaround which I explain below, but I am not sure if this will remain effective in future JDK versions. I am currently using JDK 17 but were also able to reproduce the issues with JDK 21.
>
> I have observed the following side-effects caused by managed blocks or similar mechanisms:
>
> 1. Parallel stream methods execute another task (i.e. JUnit test) from the pool recursively, which is particularly problematic if your code utilizes any ThreadLocal.
>
> 2. Blocking methods spawn around 256 threads in total to "compensate" for the blocking operation. Consequently, you end up with up to 256 tests running concurrently, each of them might or might not be CPU bound (unknown to the ForkJoinPool).
>
> 3. Blocking methods may throw a RejectedExecutionException when the thread limit is reached. This is effectively a race condition which may lead to exceptions.
>
> I have not been able to determine under which circumstances each behavior occurs. I am unaware of any thorough documentation that clearly outlines the expected behavior in different scenarios with different blocking methods. While (1.) and (3.) have caused test failures, (2.) simply causes JUnit to run 256 tests in parallel instead of the intended 12. I attached a JUnit test to reproduce (1.) and (3.), but it might not fail on every run.
>
> Many of the blocking methods of the standard library include a check if the current thread is an instance of ForkJoinWorkerThread. My current workaround involves wrapping the code that makes blocking calls into a FutureTask which is executed on another thread and then joining this task afterwards. As of now, FutureTask.get() seems not to implement any of the side-effects. As the missing instanceof-check in FutureTask makes it inconsistent with other Futures like CompletableFuture, I fear it might be considered a "bug". I would like to know a safe solution which is specified to continue to work in future JDKs.
>
I think it would be useful to understand how JUnit creates the 
ForkJoinPool. The reason is that it controls the parallelism and "max 
pool size". If there is interference due to managedBlocker then JUnit 
can set maxPoolSize to the same value as parallelism.

On the REE, this is also controlled by JUnit when it creates the FJP. 
The saturate parameter is the predicate that is determines if REE is 
thrown or the pool continues without an additional thread.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/cce86b3f/attachment-0001.htm>

From dcubed at openjdk.org  Thu Jan 18 13:11:33 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 13:11:33 GMT
Subject: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does
 not need a core file [v2]
In-Reply-To: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
References: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
Message-ID: <p2YAxLUXs8LUgtzSF1h5KRKYyOeqil6Cp7bBbrblAxI=.f8e6744c-5655-48b3-97d1-9e80fadae11c@github.com>

> A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

Daniel D. Daugherty 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/17476/files
  - new: https://git.openjdk.org/jdk/pull/17476/files/44ddcbb8..1982e5bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17476&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17476&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17476/head:pull/17476

PR: https://git.openjdk.org/jdk/pull/17476

From dcubed at openjdk.org  Thu Jan 18 13:19:26 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 13:19:26 GMT
Subject: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does
 not need a core file [v2]
In-Reply-To: <Ucl2isqJKXPR0CEk-axaV2bg-dJWW6MJAvnOZrtTtpY=.4eee1321-3a80-4ea8-b060-5116153c0814@github.com>
References: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
 <Ucl2isqJKXPR0CEk-axaV2bg-dJWW6MJAvnOZrtTtpY=.4eee1321-3a80-4ea8-b060-5116153c0814@github.com>
Message-ID: <cF3R3W5KxI8ZYFRWJCG4dqdB1XJ-QPdiqVoKNmlYEpU=.8b463eb1-add7-4cdb-a67f-2b494190b02f@github.com>

On Thu, 18 Jan 2024 07:47:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year.
>
> Good and trivial.
> 
> Copyright year needs updating.
> 
> Thanks

@dholmes-ora - Thanks for the review. Copyright year updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17476#issuecomment-1898458868

From dcubed at openjdk.org  Thu Jan 18 13:19:28 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 13:19:28 GMT
Subject: Integrated: 8321938: java/foreign/critical/TestCriticalUpcall.java
 does not need a core file
In-Reply-To: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
References: <G6x-TQjLsXFaAdVCcFzazsKoFbLQEHTzMVR927VjChY=.ec06ca5a-cbc1-4884-b48f-bffd848d22d1@github.com>
Message-ID: <72WRHqgwnj1MRZ5C7ge3mODQvn2oZW1mvDUdmvS0DMM=.2b9cb347-786b-41ea-902d-199abf3df873@github.com>

On Thu, 18 Jan 2024 00:58:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

This pull request has now been integrated.

Changeset: a22ae909
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a22ae909bc53344afd9bb6b1f08ff06858c10820
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17476

From sgehwolf at openjdk.org  Thu Jan 18 13:40:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 18 Jan 2024 13:40:16 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: <aEJ_efKL2oKtK0-WfmgmfSJfamwdhCNCxsE-uJOxcIQ=.18467bba-1187-4541-896e-3ba1b2b1ab63@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.

@mlchung Thanks for your review and code-cleanup!

> `--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.

OK.

> The help output for this option in `jlink.properties` is no longer needed and should be removed.

OK, removed locally.

> Maybe this option should be `--ignore-modified-runtime` or something explicit.

Sure. I've renamed it to `--ignore-modified-runtime`.

> 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.

The option is currently used in tests (and can also be used to verify binary equivalence of jlinking Java SE with and without packaged modules), which is a nice property to have. If the stamp file is present in one, but not the other this is sufficient to fail the equivalence test.

> 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.

Good.

> Currently, filtering plugins can be of FILTER and TRANSFORMER category.

Which filtering plugins do you see with category TRANSFORMER? `strip-java-debug-attributes` and `strip-native-debug-symbols` perhaps? Happy to move them to the FILTER 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`.

Are you suggesting to remove it?

> In addition, this change would consider that the default module path now becomes: :$JAVA_HOME/jmods:

I cannot parse this. Do you mean the default module path becoming `$JAVA_HOME` or `$JAVA_HOME/jmods`?

> I wonder if the warning about "$JAVA_HOME/jmods" not present is strictly needed.

I don't think it's needed. We could just mention `Performing a runtime-image-based jlink.` or something like that.

> 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.

Sure.

> 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. More discussion is needed and Alan may have opinions.

So would it be acceptable if I changed those plugins to restore the old behaviour if they were not requested by the user with the respective cli option? Basically, my thinking would be that `Plugin::configure` would gain extra argument so as to determined whether this is a runtime-image based link and triggered by the current jlink run with its CLI option. This should be sufficient to configure for `transform` appropriately.

> 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.

Could you enumerate the plugins that you think are currently `TRANSFORMER` and should become `FILTER`, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1898495676

From duke at openjdk.org  Thu Jan 18 14:03:32 2024
From: duke at openjdk.org (duke)
Date: Thu, 18 Jan 2024 14:03:32 GMT
Subject: Withdrawn: 8315585: Optimization for decimal to string
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: <-BcVIUWQ0iVFp_EjSW3ObK3VEAsbGEto4na7L4W7cok=.28224180-10ba-4012-b323-f1f6efe21e62@github.com>

On Mon, 2 Oct 2023 05:40:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16006

From viktor.klang at oracle.com  Thu Jan 18 14:36:07 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 18 Jan 2024 14:36:07 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>

I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/56eb0bd2/attachment-0001.htm>

From forax at univ-mlv.fr  Thu Jan 18 15:17:14 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 18 Jan 2024 16:17:14 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
Message-ID: <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Thursday, January 18, 2024 3:36:07 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
> others will want to be able to have INJECT-flags, and then people might have
> different opinions w.r.t. the default should be to clear all flags etc.

> And that's even before one looks at the composition-part of it, what are the
> flags for A.andThen(B)? (then extrapolate to N compositions and the available
> set of flags always approaches 0)

> I spent quite a bit of time on this and in the end tracking all this info, and
> making sure that the flags of implementations correspond to the actual
> behavior, just ended up costing performance for most streams and introduced an
> extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation. 

Currently only SHORT_CIRCUIT is set (if not greedy), 
see [ https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209 | https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209 ] 

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted. 

> Making specific, rare, combinations of operations faster at the expense of
> making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Thursday, 18 January 2024 10:28
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>> <core-libs-dev at openjdk.java.net>
>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> Hi R?mi,

>> You can find some of my benches here: [
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>> |
>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>> ]

>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>> didn't end up worth it when looking at the bench results over a wide array of
>> stream sizes and number of operations.

> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
> KEEP_DISTINCT and KEEP_SIZED,
> all of them say that if the stream was sorted/distinct/sized then the stream
> returned by a call to gather() is still sorted (with the same comparator),
> distinct or sized.

> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
> windowFixed is KEEP_DISTINCT.

> [CC Paul, so he can correct me if i'm saying something stupid]

> Now for the benchmarks, it depends what you want to measure, benchmarking
> streams is tricky. This is what i know about benchmarking streams.
> First, the JIT has two ways to profile types at runtime,
> Either a method takes a function as parameter
> void map(Function function) {
> function.apply(...)
> }
> and when map is called with a subtype of Function, the JIT will propagate the
> exact type when map is inlined,
> Or a method use a field
> class Op {
> Function function;

> void map() {
> function.apply(...)
> }
> }
> in that case, the VM records the profile of function.apply() and if there are
> more than two different profiles, the VM declare profile poluttion and do not
> try to optimize.

> The Stream implementation tries very hard to use only parameters instead of
> fields, that's why it does not use classical Iterator that are pull iterator (a
> filter iterator requires a field) but a Spliterator which is a push iterator,
> the element is sent as parameter of the consumer.That's also why collect does
> not use the builder pattern (that accumulate values in fields) but a Collector
> that publish the functions to be called as parameter.

> Obvisously, this is more complex than that, a Collector stores the functions in
> fields so it should not work well but the implementation uses a record that
> plays well with escape analysis. Escape analysis see the fields of an instance
> as parameters so the functions of a Collector are correctly propagated (if the
> escape analysis works). And lambdas are using invokedynamic, and the VM tries
> really hard to inline invokedynamic, so lambdas (that captures value or not)
> are routinely fully inlined with the intermediate operation of a stream.

> In your tests, i've not seen comparaisons between an existing method like map()
> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
> where the characteristics KEEP_* have an impact and their equivalent using a
> Gatherer.

>> Cheers,
>> ?

> regards,
> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>> <forax at univ-mlv.fr>
>> Sent: Wednesday, 17 January 2024 16:48
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: Gatherer: spliterator characteristics are not propagated
>> While doing some benchmarking of the Gatherer API, i've found that the
>> characteristics of the spliterator was not propagated by the method
>> Stream.gather() making the stream slower than it should.

>> As an example, there is no way when reimplementing map() using a Gatherer to say
>> that this intermediate operation keep the size, which is important if the
>> terminal operation is toList() because if the size is known, toList() will
>> presize the List and avoid the creation of an intermediary ArrayList.

>> See [
>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>> |
>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>> ]

>> I think that adding a way to propagate the spliterator characteristics through a
>> Gatherer would greatly improve the performance of commons streams (at least all
>> the ones that end with a call to toList).

>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>> something and if improving the performance is something worth changing the API.

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/60b2d44c/attachment-0001.htm>

From dcubed at openjdk.org  Thu Jan 18 15:27:42 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 15:27:42 GMT
Subject: [jdk22] RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java
 does not need a core file
Message-ID: <kWKsBrsvdmS5bbi_yVXcRd5xgN4P_4kIBQRk2qBU85M=.1053f94f-6421-4118-994f-38d5bc4b83c0@github.com>

A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

-------------

Commit messages:
 - Backport a22ae909bc53344afd9bb6b1f08ff06858c10820

Changes: https://git.openjdk.org/jdk22/pull/90/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=90&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321938
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk22/pull/90.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/90/head:pull/90

PR: https://git.openjdk.org/jdk22/pull/90

From forax at univ-mlv.fr  Thu Jan 18 15:34:12 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 18 Jan 2024 16:34:12 +0100 (CET)
Subject: Gatherer API : wildcards complaint
In-Reply-To: <MW4PR10MB5774DE2F0C6C198219EF787BFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <440278492.105063841.1705506935769.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774510AC07F81FCE2AA7EEDFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1373912389.105157231.1705520947512.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774DE2F0C6C198219EF787BFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1646194326.105813233.1705592052242.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, January 17, 2024 9:00:32 PM
> Subject: Re: Gatherer API : wildcards complaint

> Ah, now I see what you mean! Thank you \uD83D\uDC4D

> The reason for the signature of `Gatherer.of` was to mirror as much as possible
> of `Collector.of`[1] so I would argue that if we tweak the variance of one then
> we should consider tweaking it for both.

> 1: [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Collector.java#L264
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Collector.java#L264
> ]

I agree. 
In terms of code, i suppose that we will need to add some unsafe cast because the Gatherer interface should not use wildcard (it will make the code that use the Gatherer awkward) but the factory methods should use wildcards. 
Those unsafe casts are safe because function parameter types are contravariant and return type covariant but there is no way to express than in the Java type system. 

> Cheers,
> ?

R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Wednesday, 17 January 2024 20:49
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: [External] : Re: Gatherer API : wildcards complaint

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>> <core-libs-dev at openjdk.java.net>
>> Sent: Wednesday, January 17, 2024 5:49:01 PM
>> Subject: Re: Gatherer API : wildcards complaint

>> Hi R?mi,

>> Thank you for the feedback?examples would be much appreciated!

> Here is an example with an interface and a class,

> interface Counter {
> void increment ();
> int value ();
> }

> Gatherer < String , Counter , Integer > count () {
> class CounterImpl implements Counter {
> int counter ;

> @Override
> public void increment () {
> counter ++;
> }

> @Override
> public int value () {
> return counter ;
> }
> }
> Supplier < CounterImpl > initializer = CounterImpl :: new ;
> Gatherer . Integrator < Counter , String , Gatherer . Downstream <? super
> Integer >> integrator = ( counter , _ , _ ) -> {
> counter .increment();
> return true ;
> };
> BiConsumer < Counter , Gatherer . Downstream <? super Integer >> finisher = (
> counter , downstream ) -> {
> downstream .push( counter .value());
> };
> return Gatherer . ofSequential ( initializer , integrator , finisher ); // does
> not compile :(
> }

> void main () {
> System . out .println( Stream . of ( "foo"
> ).gather(count()).findFirst().orElseThrow());
> }

> if instead of explicitly typing each functions, we directly call ofSequential,
> it works

> return Gatherer . ofSequential (
> CounterImpl :: new ,
> ( Counter counter , String _ , Gatherer . Downstream <? super Integer > _ ) -> {
> counter .increment();
> return true ;
> },
> ( Counter counter , Gatherer . Downstream <? super Integer > downstream ) -> {
> downstream .push( counter .value());
> }
> );

> because here, CounterImpl::new is inferred as Supplier<Counter>.

>> Cheers,
>> ?

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>> <forax at univ-mlv.fr>
>> Sent: Wednesday, 17 January 2024 16:55
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: Gatherer API : wildcards complaint
>> Hello,
>> this is a minor complaint but I do not see a raison to not getting this right.

>> Currently the Gatherer API does not use the wildcard correctly, which is not
>> fully an issue because there is "enough" wildcards that if you rely on the
>> inference, it will work.

>> The problem is that when you write code, you make mistakes and usually when you
>> have a typing issue, a way to debug it is to fix the type arguments
>> de-activating the inference.
>> But because there are some missing wildcards, this debugging strategy just fail
>> flat with more typing errors.

>> I think that fixing the missing wildcards will hep users (or a least me) to have
>> a better experience when using the Gatherer API.

>> I can help and propose a PR if you want.

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/81d84982/attachment-0001.htm>

From ayang at openjdk.org  Thu Jan 18 15:39:18 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 18 Jan 2024 15:39:18 GMT
Subject: [jdk22] RFR: 8321938:
 java/foreign/critical/TestCriticalUpcall.java does not need a core file
In-Reply-To: <kWKsBrsvdmS5bbi_yVXcRd5xgN4P_4kIBQRk2qBU85M=.1053f94f-6421-4118-994f-38d5bc4b83c0@github.com>
References: <kWKsBrsvdmS5bbi_yVXcRd5xgN4P_4kIBQRk2qBU85M=.1053f94f-6421-4118-994f-38d5bc4b83c0@github.com>
Message-ID: <dJ1CyfCX_fw-7dw85E_qcy5uUPGY9kcEGUCYN-qFQhs=.69f38aed-344b-4fb9-b979-648bca1e9312@github.com>

On Thu, 18 Jan 2024 15:20:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/90#pullrequestreview-1829973047

From dcubed at openjdk.org  Thu Jan 18 15:42:19 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 15:42:19 GMT
Subject: [jdk22] RFR: 8321938:
 java/foreign/critical/TestCriticalUpcall.java does not need a core file
In-Reply-To: <dJ1CyfCX_fw-7dw85E_qcy5uUPGY9kcEGUCYN-qFQhs=.69f38aed-344b-4fb9-b979-648bca1e9312@github.com>
References: <kWKsBrsvdmS5bbi_yVXcRd5xgN4P_4kIBQRk2qBU85M=.1053f94f-6421-4118-994f-38d5bc4b83c0@github.com>
 <dJ1CyfCX_fw-7dw85E_qcy5uUPGY9kcEGUCYN-qFQhs=.69f38aed-344b-4fb9-b979-648bca1e9312@github.com>
Message-ID: <BfAQwp5PXVnjliE_3voKVuqday0zeKdxE0d11EKoRUQ=.6c357980-2542-4639-bad3-873c4d241c1b@github.com>

On Thu, 18 Jan 2024 15:36:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk - Thanks for the fast review!

-------------

PR Comment: https://git.openjdk.org/jdk22/pull/90#issuecomment-1898718533

From dcubed at openjdk.org  Thu Jan 18 15:42:22 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 15:42:22 GMT
Subject: [jdk22] Integrated: 8321938:
 java/foreign/critical/TestCriticalUpcall.java does not need a core file
In-Reply-To: <kWKsBrsvdmS5bbi_yVXcRd5xgN4P_4kIBQRk2qBU85M=.1053f94f-6421-4118-994f-38d5bc4b83c0@github.com>
References: <kWKsBrsvdmS5bbi_yVXcRd5xgN4P_4kIBQRk2qBU85M=.1053f94f-6421-4118-994f-38d5bc4b83c0@github.com>
Message-ID: <YUX0ZpSysPR4Wr4wpregVXrUuncyBK74BMWunw6IC_M=.eac9b77d-6f7f-47ae-bad2-1545734a40f9@github.com>

On Thu, 18 Jan 2024 15:20:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java.

This pull request has now been integrated.

Changeset: b1788944
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b17889442385752929f4cbf77f34a79678dc492a
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

Reviewed-by: ayang
Backport-of: a22ae909bc53344afd9bb6b1f08ff06858c10820

-------------

PR: https://git.openjdk.org/jdk22/pull/90

From JohannesS at lucanet.com  Thu Jan 18 16:13:16 2024
From: JohannesS at lucanet.com (Johannes Spangenberg)
Date: Thu, 18 Jan 2024 16:13:16 +0000
Subject: Avoiding Side Effects of ForkJoinPool.managedBlock
In-Reply-To: <e552b89e-b8d3-4242-b3af-64247cbf4e65@oracle.com>
References: <BEZP281MB3105275CDD47FC9D544EB1A6B8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>
 <e552b89e-b8d3-4242-b3af-64247cbf4e65@oracle.com>
Message-ID: <BEZP281MB31051FBA02E7F1D901FE6DACB8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>

> On the REE, this is also controlled by JUnit when it creates the FJP.
> The saturate parameter is the predicate that is determines if REE is
> thrown or the pool continues without an additional thread.

Thanks, I missed that unfortunately. My version of JUnit uses null for
the saturate parameter, but it has been changed in more recent versions.

https://github.com/junit-team/junit5/commit/324802d8d0e189a4bddac5a2f93e4c52d2431f5b

So, I guess (2.) and (3.) can be fixed by using a more recent version of
JUnit... Regarding (1.), I suppose there is no option to disable the
thread-stealing mechanism with parallel streams. I find it a bit
unfortunate that using a ForkJoinPool changes the behavior of various
methods which are otherwise unrelated to the ForkJoinPool. (Maybe
virtual threads can be used to fix that at some point.) Anyway, I have
everything I need right now.

Thank you again,
Johannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7798 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/debde760/smime-0001.p7s>

From viktor.klang at oracle.com  Thu Jan 18 16:14:38 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 18 Jan 2024 16:14:38 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>


And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/d30ca311/attachment-0001.htm>

From rgiulietti at openjdk.org  Thu Jan 18 17:08:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 18 Jan 2024 17:08:31 GMT
Subject: Integrated: 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: <sKOsowugtOYQoOduf9GAqPMgFWQBjQy0ULOumxTf8w0=.dd27b105-05f4-4ba1-82a2-bd4e33679781@github.com>

On Fri, 15 Dec 2023 17:34:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adds serialization misdeclaration events to JFR.

This pull request has now been integrated.

Changeset: bfd2afe5
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfd2afe5adc315928fdedbfbe73049d8774400de
Stats:     781 lines in 10 files changed: 781 ins; 0 del; 0 mod

8275338: Add JFR events for notable serialization situations

Reviewed-by: rriggs, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/17129

From jbhateja at openjdk.org  Thu Jan 18 17:10:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 Jan 2024 17:10:35 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <rmE-0addbbzxDGbBwHgtovvwWCx_gxnmlfzKXdyKN4s=.73ef2a3a-ab4a-4b4a-b6a5-20f4e13ed993@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
 <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>
 <4-XrsvK-2HpBV3neMmQQ5Q1A4FDOAnmyFtCkKKZcf2A=.32df7d9e-e399-4715-a6b5-f3f2e9c77150@github.com>
 <rmE-0addbbzxDGbBwHgtovvwWCx_gxnmlfzKXdyKN4s=.73ef2a3a-ab4a-4b4a-b6a5-20f4e13ed993@github.com>
Message-ID: <AHfBpticmm-OZyk9vxBwLDdmPoqCdaDXokb-mUrAs40=.68d8ae97-87c1-4738-9599-b92cf5157857@github.com>

On Tue, 16 Jan 2024 07:08:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Each long/double permute lane holds 64 bit value.
>
> @jatin-bhateja so why do you shift by 5? I thought 4 longs are 32 bit?

For long/double each permute row is 32 byte in size, so a shift by 5 to compute row address.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1457747672

From jbhateja at openjdk.org  Thu Jan 18 17:10:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 Jan 2024 17:10:33 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v6]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <Pdu-IRV4aTb-iO4aqhe3QXxTkXMJn8-qfjyLheYo6G0=.0ec744c1-c73f-43f2-a3f1-f66f6d4f41d1@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Space fixup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/c3f1c50e..3ed6b8bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17261/head:pull/17261

PR: https://git.openjdk.org/jdk/pull/17261

From jlaskey at openjdk.org  Thu Jan 18 17:32:11 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 18 Jan 2024 17:32:11 GMT
Subject: RFR: 8159927: Add a test to verify JMOD files created in the
 images do not have debug symbols
In-Reply-To: <grMfpKA3RUlxO8UhrNIfsbydCJ_UvJL-I9Dlt7OgccQ=.2ecff3bc-66f5-40e3-8b20-8f9978ef4258@github.com>
References: <grMfpKA3RUlxO8UhrNIfsbydCJ_UvJL-I9Dlt7OgccQ=.2ecff3bc-66f5-40e3-8b20-8f9978ef4258@github.com>
Message-ID: <dOZoFR7RgbbkbyY6tvnlEkwG-1uEpnq5od2ZVJY9PMQ=.cff449d3-dafb-42d8-bfa7-ba175cb97816@github.com>

On Wed, 17 Jan 2024 20:51:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The build excludes the native debug symbols in JMOD files created for JDK modules (see make/CreateJmods.gmk).   This PR adds a test to verify that native debug symbols are excluded as expected.

LGTM

-------------

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17467#pullrequestreview-1830228257

From dcubed at openjdk.org  Thu Jan 18 17:46:37 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 17:46:37 GMT
Subject: Integrated: 8324161: validate-source fails after JDK-8275338
Message-ID: <8XQl7SKMhyj5HQTar_rBM1WNVYa0zi_bokBZRPBT0y0=.f306fa17-3e44-4fa8-b2fe-b2938890b92d@github.com>

A trivial fix to the copyright line in test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java.

-------------

Commit messages:
 - 8324161: validate-source fails after JDK-8275338

Changes: https://git.openjdk.org/jdk/pull/17490/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324161
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17490/head:pull/17490

PR: https://git.openjdk.org/jdk/pull/17490

From darcy at openjdk.org  Thu Jan 18 17:46:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Jan 2024 17:46:37 GMT
Subject: Integrated: 8324161: validate-source fails after JDK-8275338
In-Reply-To: <8XQl7SKMhyj5HQTar_rBM1WNVYa0zi_bokBZRPBT0y0=.f306fa17-3e44-4fa8-b2fe-b2938890b92d@github.com>
References: <8XQl7SKMhyj5HQTar_rBM1WNVYa0zi_bokBZRPBT0y0=.f306fa17-3e44-4fa8-b2fe-b2938890b92d@github.com>
Message-ID: <j1WGxva_yDEoqkOIIJXOSTWEPd_oHezsvg9LuzjRtqc=.1e4d3935-134d-496b-86a2-dbf5f62899cc@github.com>

On Thu, 18 Jan 2024 17:39:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to the copyright line in test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17490#pullrequestreview-1830248699

From dcubed at openjdk.org  Thu Jan 18 17:46:38 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 17:46:38 GMT
Subject: Integrated: 8324161: validate-source fails after JDK-8275338
In-Reply-To: <j1WGxva_yDEoqkOIIJXOSTWEPd_oHezsvg9LuzjRtqc=.1e4d3935-134d-496b-86a2-dbf5f62899cc@github.com>
References: <8XQl7SKMhyj5HQTar_rBM1WNVYa0zi_bokBZRPBT0y0=.f306fa17-3e44-4fa8-b2fe-b2938890b92d@github.com>
 <j1WGxva_yDEoqkOIIJXOSTWEPd_oHezsvg9LuzjRtqc=.1e4d3935-134d-496b-86a2-dbf5f62899cc@github.com>
Message-ID: <maQrH1wSn7MsTQ7ZJovnELwlzVcbUe50802A0GhNAGE=.3eabac99-5d72-419d-9330-b16e1610b73b@github.com>

On Thu, 18 Jan 2024 17:41:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to the copyright line in test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the lightning fast review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17490#issuecomment-1898936525

From dcubed at openjdk.org  Thu Jan 18 17:46:39 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 17:46:39 GMT
Subject: Integrated: 8324161: validate-source fails after JDK-8275338
In-Reply-To: <8XQl7SKMhyj5HQTar_rBM1WNVYa0zi_bokBZRPBT0y0=.f306fa17-3e44-4fa8-b2fe-b2938890b92d@github.com>
References: <8XQl7SKMhyj5HQTar_rBM1WNVYa0zi_bokBZRPBT0y0=.f306fa17-3e44-4fa8-b2fe-b2938890b92d@github.com>
Message-ID: <DISn7zZ2NTkh7ebnpBB3_58Fs7NJr7IVPVWQhP14GYQ=.c0362de7-b4d4-405a-9dcc-61dfaaa90458@github.com>

On Thu, 18 Jan 2024 17:39:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to the copyright line in test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java.

This pull request has now been integrated.

Changeset: 5c874c19
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c874c19cb08e5c10204a7ad47fb3075f65633db
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8324161: validate-source fails after JDK-8275338

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/17490

From jlaskey at openjdk.org  Thu Jan 18 18:56:23 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 18 Jan 2024 18:56:23 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support unicode
 escapes
Message-ID: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>

Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

-------------

Commit messages:
 - Unicode escape sequences in translateEscapes

Changes: https://git.openjdk.org/jdk/pull/17491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8263261
  Stats: 56 lines in 2 files changed: 50 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From rgiulietti at openjdk.org  Thu Jan 18 19:37:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 18 Jan 2024 19:37:27 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <KvqK8jJ1Mk4N8oAykEuB1qQQuwijT4mIDlhHeEHKCOI=.b6db5c35-08b0-4ccc-9c26-a6abb51383de@github.com>

On Thu, 18 Jan 2024 18:50:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

src/java.base/share/classes/java/lang/String.java line 4274:

> 4272:                     break;
> 4273:                 case 'u':
> 4274:                     if (from + 4 <= length) {

Avoids a potential overflow
Suggestion:

                    if (from <= length - 4) {

src/java.base/share/classes/java/lang/String.java line 4281:

> 4279:                         } catch (NumberFormatException ex) {
> 4280:                             throw new IllegalArgumentException("Invalid unicode sequence: " + hex);
> 4281:                         }

Avoids an allocation on a valid sequence, but is perhaps slower.
Suggestion:

                        from += 4;
                        try {
                            ch = (char) Integer.parseInt(this, from - 4, from, 16);
                        } catch (NumberFormatException ex) {
                            throw new IllegalArgumentException("Invalid unicode sequence: " + substring(from - 4, from));
                        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1457889653
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1457897030

From naoto at openjdk.org  Thu Jan 18 19:43:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Jan 2024 19:43:27 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca` are
 incorrect
Message-ID: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>

Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/17492/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17492&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324065
  Stats: 41 lines in 6 files changed: 3 ins; 7 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/17492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17492/head:pull/17492

PR: https://git.openjdk.org/jdk/pull/17492

From jlu at openjdk.org  Thu Jan 18 20:11:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 18 Jan 2024 20:11:10 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern
In-Reply-To: <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
 <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>
Message-ID: <3hKX_Ehs3wm7zMvfwukLB_MgY9rHey6row0X9bH1ICs=.a9cb4596-7a72-4de1-ac26-7c7d9ce51479@github.com>

On Wed, 17 Jan 2024 21:31:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Hi Archie, thanks for the proposed fix. I am still taking a look, but I wanted to demonstrate a current issue,
>> 
>> (Jshell with your patch)
>> 
>> 
>> var pattIn = "Test: {0,number,foo'{'#.00}";
>> MessageFormat mFmt = new MessageFormat(pattIn);
>> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo{#.00}";
>> 
>> 
>> 
>> var pattIn = "Test: {0,number,foo'}'#.00}";
>> MessageFormat mFmt = new MessageFormat(pattIn);
>> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo'}'#.00}";
>> 
>> 
>> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted. 
>> 
>> Also in response to your earlier question on core-libs-dev, ideally invoking toPattern() can roundtrip, but there are known issues, such as a custom user defined Format subclass, or one of the newer Format subclasses that do not implement the toPattern() method. I am working on making this apparent in the specification of the method in a separate issue.
>
> Hi @justin-curtis-lu,
> 
> Thanks a lot for taking a look, I am glad for any other set of eyes on this tricky stuff!
> 
>> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted.
> 
> You're right - the problem exists with both `{` and `}`, as is shown here (unmodified jshell):
> 
> 
> $ jshell
> |  Welcome to JShell -- Version 17.0.9
> |  For an introduction type: /help intro
> 
> jshell> import java.text.*;
> 
> jshell> new MessageFormat("Test: {0,number,foo'{'#.00}");
> $2 ==> java.text.MessageFormat at 951c5b58
> 
> jshell> $2.toPattern()
> $3 ==> "Test: {0,number,foo{#.00}"
> 
> jshell> new MessageFormat($3)
> |  Exception java.lang.IllegalArgumentException: Unmatched braces in the pattern.
> |        at MessageFormat.applyPattern (MessageFormat.java:521)
> |        at MessageFormat.<init> (MessageFormat.java:371)
> |        at (#4:1)
> 
> 
> I've been missing the forest for the trees a bit and I think the fix can be simpler now.
> 
> For the record, here is my latest understanding of what's going on...
> 
> 1. When `MessageFormat.toPattern()` constructs the combined pattern string, it concatenates the plain text bits, suitably escaped, and the pattern strings from each subformat.
> 1. The subformat strings are already escaped, in the sense that you can take (for example) a `ChoiceFormat` format string and use it as-is to recreate that same `ChoiceFormat`, but they are escaped _only for their own purposes_.
> 1. The original example is an example of where this matters - `ChoiceFormat` needs to escape `#`, `|`, etc., but doesn't need to escape `{` or `}` - but a `MessageFormat` format string does need to escape those.
> 1. Therefore, the correct fix is for `MessageFormat.toPattern()` to modify the subformat strings by quoting any _unquoted_ `{` or `}` characters while leaving any already-quoted characters alone.
> 
> Updated in a9d78c76f5f. I've also updated the test so it does more thorough round-trip checks.

Hi @archiecobbs , I think the recent commit is good progress.

First off I think this change will need a CSR as there are behavioral concerns, although minimal. Please let me know if you have access on JBS to file one, otherwise I can file one for you.

> Therefore, the correct fix is for MessageFormat.toPattern() to modify the subformat strings by quoting any unquoted {or } characters while leaving any already-quoted characters alone.

Yes, I think this behavior allows for the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat. Although to clarify, the original String pattern will not be guaranteed to be equivalent to the one returned by `toPattern()` as we are adding quotes to all brackets in the subformatPattern, regardless if they were quoted in the original String. I think the former is more important here, so the latter is okay.

For DecimalFormat and SimpleDateFormat subformats, adding quotes to brackets found in the subformatPattern is always right, those subformats can not be used to create recursive format behavior. Thus you would **never** except a nested ArgumentIndex in the subformatPattern (ex: `"{0,number,{1}foo0.0"}`), and can confidently escape all brackets found for these subFormats (which you do).

To me, ChoiceFormat is where there is some concern. Consider the following,

`new MessageFormat("{0,choice,0# {1} {2} {3} }?)`

With this change, invoking `toPattern()` on the created MessageFormat would return 

`"{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }"`.

This would technically be incorrect. One would think instead of allowing 3 nested elements, we are now printing the literal `{1} {2} {3}` since the brackets are escaped. But, this is not actually the case. Escaping brackets with a choice subFormat does not function properly. This is due to the fact that a recursive messageFormat is created, but the pattern passed has already lost the quotes.

This means that `new MessageFormat("{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }")`.

is still equivalent to `new MessageFormat("{0,choice,0# {1} {2} {3} }?).`

So the behavior of quoting all brackets would still guarantee _the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat_ but only because the current behavior of formatting with a choice subFormat is technically wrong. I think this is okay, since this incorrect behavior is long-standing, but a CSR would be good to address this.

Please let me know if these points made sense, I?m happy to discuss further.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899133247

From jlaskey at openjdk.org  Thu Jan 18 20:26:16 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 18 Jan 2024 20:26:16 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes
In-Reply-To: <KvqK8jJ1Mk4N8oAykEuB1qQQuwijT4mIDlhHeEHKCOI=.b6db5c35-08b0-4ccc-9c26-a6abb51383de@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <KvqK8jJ1Mk4N8oAykEuB1qQQuwijT4mIDlhHeEHKCOI=.b6db5c35-08b0-4ccc-9c26-a6abb51383de@github.com>
Message-ID: <NhvkotUM4zoVxbYPesGMWa3LsjWw2ToBgo5YOt9CPD8=.70729ced-f6da-47ec-9342-13a3b1887e9f@github.com>

On Thu, 18 Jan 2024 19:25:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> src/java.base/share/classes/java/lang/String.java line 4274:
> 
>> 4272:                     break;
>> 4273:                 case 'u':
>> 4274:                     if (from + 4 <= length) {
> 
> Avoids a potential overflow
> Suggestion:
> 
>                     if (from <= length - 4) {

Good.

> src/java.base/share/classes/java/lang/String.java line 4281:
> 
>> 4279:                         } catch (NumberFormatException ex) {
>> 4280:                             throw new IllegalArgumentException("Invalid unicode sequence: " + hex);
>> 4281:                         }
> 
> Avoids an allocation on a valid sequence, but is perhaps slower.
> Suggestion:
> 
>                         from += 4;
>                         try {
>                             ch = (char) Integer.parseInt(this, from - 4, from, 16);
>                         } catch (NumberFormatException ex) {
>                             throw new IllegalArgumentException("Invalid unicode sequence: " + substring(from - 4, from));
>                         }

Good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1457941024
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1457941676

From jlaskey at openjdk.org  Thu Jan 18 20:35:30 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 18 Jan 2024 20:35:30 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v2]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <GvMER9PpCgPJqgXzpYOrSw2TkhUv9392qvsfHMpJs5Y=.467b1814-31b2-40e9-8585-8fea0dfa5155@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/4ae16f8b..9deac037

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From iris at openjdk.org  Thu Jan 18 20:51:11 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Jan 2024 20:51:11 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <YmFXEEi8SSunIMk1c-APzMNIrBJUInxl6iTOQ6-xjMw=.2cbbf55a-7fa3-4ab3-a077-dc6f60cdf2d6@github.com>

On Thu, 18 Jan 2024 19:37:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

Hopefully "2100" is unique enough that you'll be able to easily search/replace the next time you need to extend.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830530349

From naoto at openjdk.org  Thu Jan 18 21:02:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Jan 2024 21:02:26 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v2]
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added comment to clarify the possible need for the last year expansion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17492/files
  - new: https://git.openjdk.org/jdk/pull/17492/files/1779673d..9ce8f35b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17492&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17492&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17492/head:pull/17492

PR: https://git.openjdk.org/jdk/pull/17492

From naoto at openjdk.org  Thu Jan 18 21:02:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Jan 2024 21:02:26 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v2]
In-Reply-To: <YmFXEEi8SSunIMk1c-APzMNIrBJUInxl6iTOQ6-xjMw=.2cbbf55a-7fa3-4ab3-a077-dc6f60cdf2d6@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <YmFXEEi8SSunIMk1c-APzMNIrBJUInxl6iTOQ6-xjMw=.2cbbf55a-7fa3-4ab3-a077-dc6f60cdf2d6@github.com>
Message-ID: <Iibn9Ex67B-dxjZaEehxcLvqYcvfGsvC28WrjUiUjzQ=.9a1cfedc-b4af-481c-8976-79239eca7d9c@github.com>

On Thu, 18 Jan 2024 20:48:03 GMT, Iris Clark <iris at openjdk.org> wrote:

> Hopefully "2100" is unique enough that you'll be able to easily search/replace the next time you need to extend.

Thank you, Iris. Added a comment to clarify the need for possible expansion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17492#issuecomment-1899195604

From acobbs at openjdk.org  Thu Jan 18 21:11:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 18 Jan 2024 21:11:11 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern
In-Reply-To: <3hKX_Ehs3wm7zMvfwukLB_MgY9rHey6row0X9bH1ICs=.a9cb4596-7a72-4de1-ac26-7c7d9ce51479@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
 <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>
 <3hKX_Ehs3wm7zMvfwukLB_MgY9rHey6row0X9bH1ICs=.a9cb4596-7a72-4de1-ac26-7c7d9ce51479@github.com>
Message-ID: <97WpuyYiAg3WZVK5Z7tg1OWW3vD6H8B9Oa_roP2ndeo=.55431e6f-16ad-4d28-aa93-c0a779d23ce7@github.com>

On Thu, 18 Jan 2024 20:08:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Hi @justin-curtis-lu,
>> 
>> Thanks a lot for taking a look, I am glad for any other set of eyes on this tricky stuff!
>> 
>>> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted.
>> 
>> You're right - the problem exists with both `{` and `}`, as is shown here (unmodified jshell):
>> 
>> 
>> $ jshell
>> |  Welcome to JShell -- Version 17.0.9
>> |  For an introduction type: /help intro
>> 
>> jshell> import java.text.*;
>> 
>> jshell> new MessageFormat("Test: {0,number,foo'{'#.00}");
>> $2 ==> java.text.MessageFormat at 951c5b58
>> 
>> jshell> $2.toPattern()
>> $3 ==> "Test: {0,number,foo{#.00}"
>> 
>> jshell> new MessageFormat($3)
>> |  Exception java.lang.IllegalArgumentException: Unmatched braces in the pattern.
>> |        at MessageFormat.applyPattern (MessageFormat.java:521)
>> |        at MessageFormat.<init> (MessageFormat.java:371)
>> |        at (#4:1)
>> 
>> 
>> I've been missing the forest for the trees a bit and I think the fix can be simpler now.
>> 
>> For the record, here is my latest understanding of what's going on...
>> 
>> 1. When `MessageFormat.toPattern()` constructs the combined pattern string, it concatenates the plain text bits, suitably escaped, and the pattern strings from each subformat.
>> 1. The subformat strings are already escaped, in the sense that you can take (for example) a `ChoiceFormat` format string and use it as-is to recreate that same `ChoiceFormat`, but they are escaped _only for their own purposes_.
>> 1. The original example is an example of where this matters - `ChoiceFormat` needs to escape `#`, `|`, etc., but doesn't need to escape `{` or `}` - but a `MessageFormat` format string does need to escape those.
>> 1. Therefore, the correct fix is for `MessageFormat.toPattern()` to modify the subformat strings by quoting any _unquoted_ `{` or `}` characters while leaving any already-quoted characters alone.
>> 
>> Updated in a9d78c76f5f. I've also updated the test so it does more thorough round-trip checks.
>
> Hi @archiecobbs , I think the recent commit is good progress.
> 
> First off I think this change will need a CSR as there are behavioral concerns, although minimal. Please let me know if you have access on JBS to file one, otherwise I can file one for you.
> 
>> Therefore, the correct fix is for MessageFormat.toPattern() to modify the subformat strings by quoting any unquoted {or } characters while leaving any already-quoted characters alone.
> 
> Yes, I think this behavior allows for the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat. Although to clarify, the original String pattern will not be guaranteed to be equivalent to the one returned by `toPattern()` as we are adding quotes to all brackets in the subformatPattern, regardless if they were quoted in the original String. I think the former is more important here, so the latter is okay.
> 
> For DecimalFormat and SimpleDateFormat subformats, adding quotes to brackets found in the subformatPattern is always right, those subformats can not be used to create recursive format behavior. Thus you would **never** except a nested ArgumentIndex in the subformatPattern (ex: `"{0,number,{1}foo0.0"}`), and can confidently escape all brackets found for these subFormats (which you do).
> 
> To me, ChoiceFormat is where there is some concern. Consider the following,
> 
> `new MessageFormat("{0,choice,0# {1} {2} {3} }?)`
> 
> With this change, invoking `toPattern()` on the created MessageFormat would return 
> 
> `"{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }"`.
> 
> This would technically be incorrect. One would think instead of allowing 3 nested elements, we are now printing the literal `{1} {2} {3}` since the brackets are escaped. But, this is not actually the case. Escaping brackets with a choice subFormat does not function properly. This is due to the fact that a recursive messageFormat is created, but the pattern passed has already lost the quotes.
> 
> This means that `new MessageFormat("{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }")`.
> 
> is still equivalent to `new MessageFormat("{0,choice,0# {1} {2} {3} }?).`
> 
> So the behavior of quoting all brackets would still guarantee _the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat_ but only because the current behavior of formatting with a choice subFormat is technically wrong. I think this is okay, since this incorrect behavior is long-standing, but a CSR would be good to ad...

Hi @justin-curtis-lu,

Thanks for your comments.

> First off I think this change will need a CSR as there are behavioral concerns, although minimal. Please let me know if you have access on JBS to file one, otherwise I can file one for you.

No problem, I'll add one.

> To me, ChoiceFormat is where there is some concern. Consider the following,

OK I think I understand what you're saying.

The first goal here is to ensure the round trip operation `MessageFormat` ? Pattern string from `toPattern()` ? `MessageFormat` takes you back to where you started.

The patch achieves this so we're good so far. I think we agree on this.

> This would technically be incorrect.

I'm not quite understanding what you meant there (and therefore slightly worried)...

In my mind, a key observation here is that the following two things are not equal and therefore shouldn't be conflated:
* A `ChoiceFormat` pattern string (e.g., what you get from invoking `ChoiceFormat.toPattern()`)
* The `XXX` that you see inside a `MessageFormat` pattern string as part of a `{0,choice,XXX}` subformat.

Those are not the same, even modulo quoting. As you point out, `MessageFormat` has this quirky logic ([here](https://github.com/openjdk/jdk/blob/81df265e41d393cdde87729e091dd465934071fd/src/java.base/share/classes/java/text/MessageFormat.java#L1327-L1333)) in which, after it evaluates a `ChoiceFormat` subformat, if the returned string contains a `{` character, then that string is magically reinterpreted as a `MessageFormat` pattern string and evaluated again, otherwise it's left alone.

So the `XXX` is not a "`ChoiceFormat` pattern string" but something else, so it can't be "incorrect" for not looking like a normal `ChoiceFormat` pattern string.

Maybe it's just a manner of speaking? In any case I want to be careful I'm not missing something in what you're saying.

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899206551

From duke at openjdk.org  Thu Jan 18 21:38:55 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Thu, 18 Jan 2024 21:38:55 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: <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@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

Hello Vamsi (@vamsi-parasa),

Could you please run the benchmarking of new DQPS in your environment with AVX?

Take all classes below and put them in the package org.openjdk.bench.java.util.
ArraysSort class contains all tests for the new versions and ready to use.
(it will run all tests in one execution).

https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java

Many thanks,
Vladimir

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1899240013

From mchung at openjdk.org  Thu Jan 18 21:40:17 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 18 Jan 2024 21:40:17 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <aEJ_efKL2oKtK0-WfmgmfSJfamwdhCNCxsE-uJOxcIQ=.18467bba-1187-4541-896e-3ba1b2b1ab63@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>
 <aEJ_efKL2oKtK0-WfmgmfSJfamwdhCNCxsE-uJOxcIQ=.18467bba-1187-4541-896e-3ba1b2b1ab63@github.com>
Message-ID: <oOdi9t6sNDmcOr7z5pgoIqeQIYJFZ2CnnC8Ix0rue-g=.ea771691-0683-4bbb-9a6c-7a029340d5d6@github.com>

On Thu, 18 Jan 2024 13:37:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > 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.
> 
> The option is currently used in tests (and can also be used to verify binary equivalence of jlinking Java SE with and without packaged modules), which is a nice property to have. If the stamp file is present in one, but not the other this is sufficient to fail the equivalence test.

What I tried to point out is the following:

1. run `myruntime/bin/jlink` to create `image1` without packaged module
2. run `image1/bin/jlink` to create a runtime image will fail
3. run `image1/bin/jlink --ignore-modified-runtime` will successfully to create `image2`

I expect `image2/bin/jlink` should fail creating a runtime image since it's multi-hop.   Another scenario: If I modify `image2/conf/net.properties` , `image2/bin/jlink` should fail.  In both cases, `image2/bin/jlink --ignore-modified-runtime` will ignore the error and create the runtime image.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1899238507

From mchung at openjdk.org  Thu Jan 18 21:40:19 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 18 Jan 2024 21:40:19 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: <1ERrMLj7c_vm34qrhdFA6lJs5ExV6ffxpoa9lCZbw88=.e455b7db-87d8-4ed2-b984-cbdbb5c6ecb6@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.

`JRTArchive::collectFiles` is the relevant code:


            // add/persist a special, empty file for jdk.jlink so as to support
            // the single-hop-only run-time image jlink
            if (singleHop && JDK_JLINK_MODULE.equals(module)) {
                files.add(createRuntimeImageSingleHopStamp());
            }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1899240758

From mchung at openjdk.org  Thu Jan 18 21:51:09 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 18 Jan 2024 21:51:09 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: <6Ge-96jo7vTa8SxtboDXu0Xe_xXEdwoc-EU4-yY2dhA=.1248d42a-d7df-4b87-8409-1dbaf7484c00@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.

> Which filtering plugins do you see with category TRANSFORMER? perhaps? Happy to move them to the FILTER category.

Yes `strip-java-debug-attributes` and `strip-native-debug-symbols`  are the ones.  `dedup-legal-notices` is another one.

> > 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. More discussion is needed and Alan may have opinions.
> 
> So would it be acceptable if I changed those plugins to restore the old behaviour if they were not requested by the user with the respective cli option? Basically, my thinking would be that `Plugin::configure` would gain extra argument so as to determined whether this is a runtime-image based link and triggered by the current jlink run with its CLI option. This should be sufficient to configure for `transform` appropriately.

My intent is to bring up my observation for discussion.   The plugin authors are the ones who should decide if the plugin should restore the data from the runtime image to original form.    It needs a way to indicate that the transformed data won't persist for this plugin.  So far I think `FILTER` category may be adequate but it may be better to define a new type.   This requires some prototype to determine what is the right way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1899261182

From iris at openjdk.org  Thu Jan 18 22:11:56 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Jan 2024 22:11:56 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v2]
In-Reply-To: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
Message-ID: <NG1GvIzUF-IZ-c1vQaN1jIZlihtRlPeAcsoHDMtmj08=.9a55e589-d5f1-4bef-9e2d-f49f340cd5cc@github.com>

On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to clarify the possible need for the last year expansion

Still looks good!

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830637536

From joehw at openjdk.org  Thu Jan 18 22:19:29 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 18 Jan 2024 22:19:29 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v2]
In-Reply-To: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
Message-ID: <S740Smj_icz7OKNnczQZiBDFbYhuo253Wsmv_oUwsuc=.138f2755-4b28-4ea4-baa4-f04f5aad9cab@github.com>

On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to clarify the possible need for the last year expansion

You've saved generations of engineers from having to look at it again. By then, the dev AI will look at it and ...

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830645855

From prappo at openjdk.org  Thu Jan 18 22:31:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 18 Jan 2024 22:31:38 GMT
Subject: Integrated: 8324053: Use the blessed modifier order for sealed in
 java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <TVu7K-1CyqlKX5fiNl8LXzQPAPkzbEtmioWPJh_LMSc=.23a8fe26-baf6-4575-89cc-92371f855656@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

This pull request has now been integrated.

Changeset: 9efdd242
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9efdd242fb40a8270e489cc071ff1c891878e24f
Stats:     8 lines in 7 files changed: 0 ins; 0 del; 8 mod

8324053: Use the blessed modifier order for sealed in java.base

Reviewed-by: naoto, darcy, ihse, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/17468

From jlu at openjdk.org  Thu Jan 18 23:05:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 18 Jan 2024 23:05:26 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v2]
In-Reply-To: <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>
Message-ID: <koZD0AtJ06MmrIywQtjzPzSqLh6zgFUbAmWPdJiiSI4=.54ba03cc-1b53-4a50-a8b2-69ef7d01ddcd@github.com>

On Wed, 17 Jan 2024 21:31:22 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Quote '{' and '}' in subformat patterns, but only it not already quoted.

Hi Archie,

> The XXX that you see inside a MessageFormat pattern string as part of a {0,choice,XXX} subformat.

I think we both agree that XXX may not be the same as the Subformat pattern string.

Sorry if I'm going over stuff you already know, but to clarify my previous statement, MessageFormat escapes brackets so that they are syntactically not evaluated and simply injected into the pattern as a literal bracket. Why I brought up ChoiceFormat, is that it is unique in the sense that you can insert a `{ FormatElement }` into a subFormat pattern, which causes recursion.

Take the example from the class specification, 

`new MessageFormat(There {0,choice,0#are no files|1#is one file|1<are {0,number,integer} files}.?);`

Formatting the value `5`, MessageFormat will first evaluate it as `are {0,number,integer} files}` and then recursively create another MessageFormat to evaluate it as `5 files`.

This is because `1<are {0,number,integer} files.` has unquoted brackets, signaling that MessageFormat should interpret them as syntactically significant. Had they been quoted such as, `1<are '{'0,number,integer'}' files.}`, **I** would expect that MessageFormat will first evaluate it as `are ?{'0,number,integer?}' files.`, and as the brackets are quoted, interpret them as syntactically meaningless and simply return the value `are {0,number,integer} files.` with no recursive MessageFormat created.


So bringing it back to my example in the previous comment, if we had `new MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` I we would expect it to format `5 6 7 8` as `foo 6 7 8`. 

But if we had `new MessageFormat("{0,choice,0.0#foo '{'1'}' '{'2'}' '{'3'}' }")` which implies the brackets are syntactically meaningless, I would expect the class to treat them not as nested `FormatElement`s and expect the returned value `foo {0} {1} {2}`

But this is not the case, since by the time the recursive MessageFormat is created the quotes are lost, so it has no means of knowing to treat them as syntactically insignificant, and thus parses the quote and treats them as injected `FormatElement`s which is why in reality the most recent example returns the value `foo 6 7 8`.

So with this change, although calling `toPattern()` on `new MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` would return the String `"{0,choice,0.0#foo '{'1'}' '{'2'}' '{'3'}' }"` which **I** would think, formats differently, **in reality**, they format equivalently, so I think it is okay. I brought it up not necessarily as an issue, but just something to make apparent. Although I suppose something like this is up for interpretation, so perhaps its only wrong to me.

I'm taking a look at the CSR you filed, but you may also want someone with Reviewer status to take a look as well.
I'll also test your changes against our internal tests. Hope this helped.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899355910

From jlu at openjdk.org  Thu Jan 18 23:22:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 18 Jan 2024 23:22:36 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v2]
In-Reply-To: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
Message-ID: <2DCaL0E-6tyxiBQBcMQycu73kyFkxghhyDy4nr7g36w=.bcecf044-1965-4602-9198-fa1228e57c38@github.com>

On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to clarify the possible need for the last year expansion

LGTM, _NegativeDSTTest.java_ can bump the copyright year to 2024 as well.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830712470

From acobbs at openjdk.org  Thu Jan 18 23:37:24 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 18 Jan 2024 23:37:24 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v2]
In-Reply-To: <koZD0AtJ06MmrIywQtjzPzSqLh6zgFUbAmWPdJiiSI4=.54ba03cc-1b53-4a50-a8b2-69ef7d01ddcd@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>
 <koZD0AtJ06MmrIywQtjzPzSqLh6zgFUbAmWPdJiiSI4=.54ba03cc-1b53-4a50-a8b2-69ef7d01ddcd@github.com>
Message-ID: <6WkTom9bwIDQZ4456ADDqFWiA8uNNNMBPyg84smj06U=.e7307a5b-7326-4b93-9bbc-f460ebb2a213@github.com>

On Thu, 18 Jan 2024 23:02:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Sorry if I'm going over stuff you already know...

No apology needed, this stuff is obscure detail madness!

> So with this change, although calling `toPattern()` on `new MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` would return the String `"{0,choice,0.0#foo '{'1'}' '{'2'}' '{'3'}' }"` which **I** would think, formats differently, **in reality**, they format equivalently, so I think it is okay. I brought it up not necessarily as an issue, but just something to make apparent. Although I suppose something like this is up for interpretation, so perhaps its only wrong to me.

OK gotcha. I totally agree that what you think it should do makes a lot more sense that what it actually does!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899385354

From sspitsyn at openjdk.org  Thu Jan 18 23:38:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Jan 2024 23:38:26 GMT
Subject: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be
 static [v2]
In-Reply-To: <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
References: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
 <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
Message-ID: <a_URc0dR0Logfqozn8Q9lnKnuHpQHsVk6QUp_pPNF4M=.c3aef735-95fe-420c-b1bf-e1425b12c849@github.com>

On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
>> The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
>> The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
>> One detail to underline is the intrinsic implementation needs to use the argument #0 instead of #1.
>> 
>> Testing:
>> - The mach5 tiers 1-6 show no regressions
>
> Serguei Spitsyn has updated the pull request with a new target base 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
>  - 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

PING! It would be nice to get this reviewed. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17298#issuecomment-1899386396

From naoto at openjdk.org  Fri Jan 19 00:07:20 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jan 2024 00:07:20 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v3]
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <rkvWP6yDRQbKNmnCUfzJn5s-czYmfdidavbu88W5oT8=.8fa6c231-8f57-4767-a94f-85bd018a79e0@github.com>

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17492/files
  - new: https://git.openjdk.org/jdk/pull/17492/files/9ce8f35b..cb652b81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17492&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17492&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17492/head:pull/17492

PR: https://git.openjdk.org/jdk/pull/17492

From naoto at openjdk.org  Fri Jan 19 00:07:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jan 2024 00:07:22 GMT
Subject: RFR: 8324065: Daylight saving information for `Africa/Casablanca`
 are incorrect [v2]
In-Reply-To: <2DCaL0E-6tyxiBQBcMQycu73kyFkxghhyDy4nr7g36w=.bcecf044-1965-4602-9198-fa1228e57c38@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
 <2DCaL0E-6tyxiBQBcMQycu73kyFkxghhyDy4nr7g36w=.bcecf044-1965-4602-9198-fa1228e57c38@github.com>
Message-ID: <4J8OkfpJ8D3uJb4GHWF1GM0pIru1Kv7douvXUbupiZY=.778f60d0-5186-4079-979e-e4425a7cdf5c@github.com>

On Thu, 18 Jan 2024 23:19:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

> LGTM, _NegativeDSTTest.java_ can bump the copyright year to 2024 as well.

Forgot that! Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17492#issuecomment-1899410249

From david.holmes at oracle.com  Fri Jan 19 01:34:41 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Jan 2024 11:34:41 +1000
Subject: Avoiding Side Effects of ForkJoinPool.managedBlock
In-Reply-To: <BEZP281MB3105275CDD47FC9D544EB1A6B8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>
References: <BEZP281MB3105275CDD47FC9D544EB1A6B8712@BEZP281MB3105.DEUP281.PROD.OUTLOOK.COM>
Message-ID: <e843f4e0-9308-4c5e-9cfe-9eb0c2743760@oracle.com>

On 18/01/2024 7:30 pm, Johannes Spangenberg wrote:
> Hello,
> 
> I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change the behavior of the code. These changes in behavior have resulted in non-deterministic test failures in one of the repositories I work on. JUnit uses a ForkJoinPool when you enable parallel test execution. I would like to disable or avoid the side effects of various methods if called from a ForkJoinPool. So far, I haven't found a solution, except for completely replacing the use of the ForkJoinPool in JUnit with some custom scheduler which is not a ForkJoinPool.
> 
> Is there a solution to force an "unmanaged" block (as opposed to ForkJoinPool.managedBlock)? Is there alternatively a good approach to transfer CPU bound subtasks to another thread pool while blocking the ForkJoinWorkerThread without compensation? I have implemented a workaround which I explain below, but I am not sure if this will remain effective in future JDK versions. I am currently using JDK 17 but were also able to reproduce the issues with JDK 21.
> 
> I have observed the following side-effects caused by managed blocks or similar mechanisms:
> 
> 1. Parallel stream methods execute another task (i.e. JUnit test) from the pool recursively, which is particularly problematic if your code utilizes any ThreadLocal.

The parallel stream implementation utilises the current ForkJoinPool, if 
any, else the common FJP.

David
-----

> 2. Blocking methods spawn around 256 threads in total to "compensate" for the blocking operation. Consequently, you end up with up to 256 tests running concurrently, each of them might or might not be CPU bound (unknown to the ForkJoinPool).
> 
> 3. Blocking methods may throw a RejectedExecutionException when the thread limit is reached. This is effectively a race condition which may lead to exceptions.
> 
> I have not been able to determine under which circumstances each behavior occurs. I am unaware of any thorough documentation that clearly outlines the expected behavior in different scenarios with different blocking methods. While (1.) and (3.) have caused test failures, (2.) simply causes JUnit to run 256 tests in parallel instead of the intended 12. I attached a JUnit test to reproduce (1.) and (3.), but it might not fail on every run.
> 
> Many of the blocking methods of the standard library include a check if the current thread is an instance of ForkJoinWorkerThread. My current workaround involves wrapping the code that makes blocking calls into a FutureTask which is executed on another thread and then joining this task afterwards. As of now, FutureTask.get() seems not to implement any of the side-effects. As the missing instanceof-check in FutureTask makes it inconsistent with other Futures like CompletableFuture, I fear it might be considered a "bug". I would like to know a safe solution which is specified to continue to work in future JDKs.
> 
> PS: There is also a ticket on the JUnit project about this topic, but it only talks about side-effect (2.), but not the other side-effects we observed.
> https://github.com/junit-team/junit5/issues/3108
> 
> Thanks,
> Johannes
> 

From dholmes at openjdk.org  Fri Jan 19 01:58:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jan 2024 01:58:29 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <QPfyDe4CjN99Z753dMkklMRksH7QWQAdZFzZDcouJq4=.b37bd9c7-f640-4976-ad17-8029a26f7fb5@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <dxBcuBLhFh50qFsePFEXYzVeOh6aM3qsDbjf4Ey96cs=.e7c0c4e8-528b-4008-b548-400763a4c29d@github.com>
 <euHlol2zVrwTTS5SzpQK9qeLTXYXK7daM0Ah3BijnOA=.26dbf1c9-8886-4b49-aa80-1f4b2a595592@github.com>
 <QPfyDe4CjN99Z753dMkklMRksH7QWQAdZFzZDcouJq4=.b37bd9c7-f640-4976-ad17-8029a26f7fb5@github.com>
Message-ID: <esAqVjr9oe5dxy-3m3O19OYg5j0PPq4A77U-TQr4yMg=.a0534c82-a7c4-48fa-bc07-bd33ff8fbe4e@github.com>

On Thu, 18 Jan 2024 09:21:24 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> It is really safe/correct to move this outside the synchronized block? I know things have changed a bit with loom but we've "always" held a lock when doing the actual interrupt. I'd have to check the VM logic to be sure it can be called concurrently from multiple threads for the same target thread.
>> 
>> This hasn't changed. The interruptLock is used to coordinate the add/remove of the nioBlocker. When there is no nioBlocker set then the interrupt status and unparking (as in JavaThread::interrupt) has always executed without the interruptLock (named "blockerLock" in the past).
>
> I think that interrupting is just asynchronous to some extent.
> E.g. a thread polls its interrupt status clearing it thereby (without lock) before calling nio. A concurrent interrupt can be lost then even if the lock is acquired.
> (Maybe clearing should not be done by a public method)

Yep my bad on the VM side of things - no change there. But in the nioBlocker case doesn't this inherently make things more racy? Now maybe those races are allowed, but this might lead to a change in behaviour.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1458188281

From epeter at openjdk.org  Fri Jan 19 07:46:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 19 Jan 2024 07:46:28 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <AHfBpticmm-OZyk9vxBwLDdmPoqCdaDXokb-mUrAs40=.68d8ae97-87c1-4738-9599-b92cf5157857@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
 <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>
 <4-XrsvK-2HpBV3neMmQQ5Q1A4FDOAnmyFtCkKKZcf2A=.32df7d9e-e399-4715-a6b5-f3f2e9c77150@github.com>
 <rmE-0addbbzxDGbBwHgtovvwWCx_gxnmlfzKXdyKN4s=.73ef2a3a-ab4a-4b4a-b6a5-20f4e13ed993@github.com>
 <AHfBpticmm-OZyk9vxBwLDdmPoqCdaDXokb-mUrAs40=.68d8ae97-87c1-4738-9599-b92cf5157857@github.com>
Message-ID: <DM9gvu3g8Wg9l7j3QqORRcTMjj2KEgKqL99sLkLFfWM=.5c842551-ebef-421b-acb7-47ef38424115@github.com>

On Thu, 18 Jan 2024 17:06:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @jatin-bhateja so why do you shift by 5? I thought 4 longs are 32 bit?
>
> For long/double each permute row is 32 byte in size, so a shift by 5 to compute row address.

Ah right. Maybe we could say `32byte = 4 long = 4 * 64bit`.
Because "64bit row" sounds like the whole row is only 64 bit long. It is actually the cells that are 64bits, not the rows!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1458509886

From rrich at openjdk.org  Fri Jan 19 07:50:26 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Jan 2024 07:50:26 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
Message-ID: <N8I8nadtXcOm9QFhDnLAkE20UbW9fppXOlFkOVP9dZw=.d0c2d24f-a25b-49d8-9020-be13b76a92e6@github.com>

On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

I noticed that VirtualThread overrides `isInterrupted` 

https://github.com/openjdk/jdk/blob/05dad67cc23fb49627fabfb306acee247ff67aef/src/java.base/share/classes/java/lang/VirtualThread.java#L902-L905

with just the same implementation as Thread has:

https://github.com/openjdk/jdk/blob/05dad67cc23fb49627fabfb306acee247ff67aef/src/java.base/share/classes/java/lang/Thread.java#L1741-L1751

This potentially hinders performance. Is there a reason to have this override?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1899918903

From alanb at openjdk.org  Fri Jan 19 08:00:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Jan 2024 08:00:26 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
Message-ID: <ZMOlv7WsZx6RowkT5cnuf06CXKkVAcFrPcCpPZvOHS8=.f6f2e11d-a869-405e-ab32-3c25ead0bdd5@github.com>

On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

> I noticed that VirtualThread overrides `isInterrupted`
> Is there a reason to have this override?

It was necessary at one point but no reason to now except to keep it close at the source level with the other methods that access the interrupt status.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1899930062

From alanb at openjdk.org  Fri Jan 19 08:04:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Jan 2024 08:04:28 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <esAqVjr9oe5dxy-3m3O19OYg5j0PPq4A77U-TQr4yMg=.a0534c82-a7c4-48fa-bc07-bd33ff8fbe4e@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <dxBcuBLhFh50qFsePFEXYzVeOh6aM3qsDbjf4Ey96cs=.e7c0c4e8-528b-4008-b548-400763a4c29d@github.com>
 <euHlol2zVrwTTS5SzpQK9qeLTXYXK7daM0Ah3BijnOA=.26dbf1c9-8886-4b49-aa80-1f4b2a595592@github.com>
 <QPfyDe4CjN99Z753dMkklMRksH7QWQAdZFzZDcouJq4=.b37bd9c7-f640-4976-ad17-8029a26f7fb5@github.com>
 <esAqVjr9oe5dxy-3m3O19OYg5j0PPq4A77U-TQr4yMg=.a0534c82-a7c4-48fa-bc07-bd33ff8fbe4e@github.com>
Message-ID: <j73g1otKEgDtK6vJwJkZPyU60jeuIU5QTWet9XLz6os=.8068c0c1-0524-45d7-9c34-78afe983ec08@github.com>

On Fri, 19 Jan 2024 01:56:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Yep my bad on the VM side of things - no change there. But in the nioBlocker case doesn't this inherently make things more racy? Now maybe those races are allowed, but this might lead to a change in behaviour.

I/O threads always check their interrupt status after installing the nioBlocker. The interruptible and the I/O thread (may several) may race calling postInterrupt but that is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1458533890

From rrich at openjdk.org  Fri Jan 19 08:19:26 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Jan 2024 08:19:26 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <ZMOlv7WsZx6RowkT5cnuf06CXKkVAcFrPcCpPZvOHS8=.f6f2e11d-a869-405e-ab32-3c25ead0bdd5@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <ZMOlv7WsZx6RowkT5cnuf06CXKkVAcFrPcCpPZvOHS8=.f6f2e11d-a869-405e-ab32-3c25ead0bdd5@github.com>
Message-ID: <fSoO4ET48YhP9ynVaTqNT0QynMmsprbyFOY0uKTjrks=.a4c6df1f-8208-4453-b005-4f36709f3c84@github.com>

On Fri, 19 Jan 2024 07:57:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I noticed that VirtualThread overrides `isInterrupted`
> > Is there a reason to have this override?
> 
> It was necessary at one point but no reason to now except to keep it close at the source level with the other methods that access the interrupt status.

Do you want to keep it then or should I open an RFE to remove it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1899953186

From jlaskey at openjdk.org  Fri Jan 19 12:16:54 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 19 Jan 2024 12:16:54 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v3]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <TOy5uSiZNxgd02smBZ24286cKiCngMSDzOGME3iQ56g=.28aeda0d-a941-475a-b349-7bc374eb9333@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey 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/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/9deac037..ff63287c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From jlaskey at openjdk.org  Fri Jan 19 12:26:51 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 19 Jan 2024 12:26:51 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v4]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <vuWoly0dZHz6d4Rfg5fdGv-S4oblz1Z8sOdoCKtzOlQ=.a8f7c047-99fe-4f1c-b700-106c4b2341a5@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/ff63287c..8359ec9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From rgiulietti at openjdk.org  Fri Jan 19 13:15:25 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 19 Jan 2024 13:15:25 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v4]
In-Reply-To: <vuWoly0dZHz6d4Rfg5fdGv-S4oblz1Z8sOdoCKtzOlQ=.a8f7c047-99fe-4f1c-b700-106c4b2341a5@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <vuWoly0dZHz6d4Rfg5fdGv-S4oblz1Z8sOdoCKtzOlQ=.a8f7c047-99fe-4f1c-b700-106c4b2341a5@github.com>
Message-ID: <qaC0pLwe6TG9hf4HKdXGHSRqSyHzQ9Ey6ob3Q4HmR9E=.7936bbe7-a91e-47d1-81c5-f049ec36c4f3@github.com>

On Fri, 19 Jan 2024 12:26:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

@JimLaskey Please update the test file copyright year as well.
Otherwise LGTM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17491#issuecomment-1900405533

From jlaskey at openjdk.org  Fri Jan 19 13:29:50 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 19 Jan 2024 13:29:50 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v5]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <HlkMTGJiTM8r_nqPizFlUYSXpTYq2TJLT9Gfl9_aJFI=.b8492e53-8d73-486e-8e4f-ebef75e09d25@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add JLS Unicode Escapes reference

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/8359ec9e..14b2f6c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From pchilanomate at openjdk.org  Fri Jan 19 14:00:27 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Jan 2024 14:00:27 GMT
Subject: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be
 static [v2]
In-Reply-To: <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
References: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
 <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
Message-ID: <DbZSaPC5tj58L9RtVCGGn4E8e9WWdfwIEmIucxr3cRI=.afc7127c-20df-4bcb-8c8a-df5cdc4f81dc@github.com>

On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
>> The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
>> The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
>> One detail to underline is the intrinsic implementation needs to use the argument #0 instead of #1.
>> 
>> Testing:
>> - The mach5 tiers 1-6 show no regressions
>
> Serguei Spitsyn has updated the pull request with a new target base 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
>  - 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

Looks good to me. I'm confused about the description saying this method is a no-op if the current thread is a platform thread.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17298#pullrequestreview-1832725029

From rgiulietti at openjdk.org  Fri Jan 19 14:14:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 19 Jan 2024 14:14:27 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v6]
In-Reply-To: <2S_wsqXlgCtqH7B1T91ey2m8fTfXCiLXKRQFZDxMrPI=.7b1c4f09-0535-447e-93fb-3ec768c2e50e@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <2S_wsqXlgCtqH7B1T91ey2m8fTfXCiLXKRQFZDxMrPI=.7b1c4f09-0535-447e-93fb-3ec768c2e50e@github.com>
Message-ID: <VyuGFsuObf8005hdm5lCUf1v2RUoblmim2PsJOCNd-k=.e294617d-fc03-4db3-b697-6e4703fb5ee3@github.com>

On Fri, 19 Jan 2024 14:10:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year of test

Looks good

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17491#pullrequestreview-1832778162

From jlaskey at openjdk.org  Fri Jan 19 14:14:26 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 19 Jan 2024 14:14:26 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v6]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <2S_wsqXlgCtqH7B1T91ey2m8fTfXCiLXKRQFZDxMrPI=.7b1c4f09-0535-447e-93fb-3ec768c2e50e@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year of test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/14b2f6c2..79312823

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From alanb at openjdk.org  Fri Jan 19 14:51:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Jan 2024 14:51:26 GMT
Subject: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be
 static [v2]
In-Reply-To: <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
References: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
 <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
Message-ID: <zRMbbd8peyLrhvUlKQ5FImiWPt4i6zca5oExhLT_Aig=.b725feec-e804-468e-97b1-b4d3ceffbe27@github.com>

On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
>> The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
>> The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
>> One detail to underline is the intrinsic implementation needs to use the argument #0 instead of #1.
>> 
>> Testing:
>> - The mach5 tiers 1-6 show no regressions
>
> Serguei Spitsyn has updated the pull request with a new target base 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
>  - 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17298#pullrequestreview-1832909249

From rgiulietti at openjdk.org  Fri Jan 19 17:42:28 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 19 Jan 2024 17:42:28 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v6]
In-Reply-To: <2S_wsqXlgCtqH7B1T91ey2m8fTfXCiLXKRQFZDxMrPI=.7b1c4f09-0535-447e-93fb-3ec768c2e50e@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <2S_wsqXlgCtqH7B1T91ey2m8fTfXCiLXKRQFZDxMrPI=.7b1c4f09-0535-447e-93fb-3ec768c2e50e@github.com>
Message-ID: <fwMy05TAq6clKrPCyh9V862HGoCAPTEFF8OEhKIc15Y=.313f204b-e031-41c3-a2ab-2a3bc176eec8@github.com>

On Fri, 19 Jan 2024 14:14:26 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year of test

test/jdk/java/lang/String/TranslateEscapes.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2024 Oracle and/or its affiliates. All rights reserved.

Sorry for this late note.
Seems like each copyright year must be followed by a comma `,`, otherwise validate-source fails. See, for example, my own oversight [here](https://github.com/openjdk/jdk/pull/17490/files).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1459422630

From mchung at openjdk.org  Fri Jan 19 17:45:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 19 Jan 2024 17:45:37 GMT
Subject: Integrated: 8159927: Add a test to verify JMOD files created in the
 images do not have debug symbols
In-Reply-To: <grMfpKA3RUlxO8UhrNIfsbydCJ_UvJL-I9Dlt7OgccQ=.2ecff3bc-66f5-40e3-8b20-8f9978ef4258@github.com>
References: <grMfpKA3RUlxO8UhrNIfsbydCJ_UvJL-I9Dlt7OgccQ=.2ecff3bc-66f5-40e3-8b20-8f9978ef4258@github.com>
Message-ID: <HgsJO2vDUvBU5amkh43ZJd7BnI8KYkZ8qTrzPl_4yL8=.e2139389-f1fb-4edc-b554-8728cb78b9a8@github.com>

On Wed, 17 Jan 2024 20:51:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The build excludes the native debug symbols in JMOD files created for JDK modules (see make/CreateJmods.gmk).   This PR adds a test to verify that native debug symbols are excluded as expected.

This pull request has now been integrated.

Changeset: 6c0bebcc
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c0bebccb0092d9726eb89a054e023e92edf7ca6
Stats:     76 lines in 1 file changed: 76 ins; 0 del; 0 mod

8159927: Add a test to verify JMOD files created in the images do not have debug symbols

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.org/jdk/pull/17467

From jlaskey at openjdk.org  Fri Jan 19 18:23:40 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 19 Jan 2024 18:23:40 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v7]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <rcKlB6jaG0Y42hQdSk6rspyvWIVhRnceWC0WKn2wahI=.4298480f-eea4-40c3-a3be-18de0870397e@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/79312823..2eb5c194

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From rriggs at openjdk.org  Fri Jan 19 18:31:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Jan 2024 18:31:33 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v7]
In-Reply-To: <rcKlB6jaG0Y42hQdSk6rspyvWIVhRnceWC0WKn2wahI=.4298480f-eea4-40c3-a3be-18de0870397e@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <rcKlB6jaG0Y42hQdSk6rspyvWIVhRnceWC0WKn2wahI=.4298480f-eea4-40c3-a3be-18de0870397e@github.com>
Message-ID: <BBVrlM0S7AIbiv60AyHl51bJgBF6n72ALAfsofM38Vk=.867d8433-e06a-4397-bd1a-6a3b485fd626@github.com>

On Fri, 19 Jan 2024 18:23:40 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright

test/jdk/java/lang/String/TranslateEscapes.java line 113:

> 111:     }
> 112: 
> 113:     static void verifyEscape(String string1, String string2) {

These are unicode escapes too.  The method name should reflect that.

test/jdk/java/lang/String/TranslateEscapes.java line 127:

> 125:         } catch (IllegalArgumentException ex) {
> 126:         }
> 127:     }

The method name implies valid unicode escape sequences, but they are all invalid.
The method name could be "verifyIllegalUnicodeEscape`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1459509112
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1459505939

From duke at openjdk.org  Fri Jan 19 18:41:29 2024
From: duke at openjdk.org (Joshua Cao)
Date: Fri, 19 Jan 2024 18:41:29 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v3]
In-Reply-To: <mN__lEll2Wdwg-Xvqnhwbf3Zemi459wCsYtp6vyOsb4=.a450e1d5-63c3-472e-bfd0-82665245e309@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
 <453O0eMb98HWkQb2yUY95T43KnSs9eBUY-f9EabFXwU=.44cdc1f9-251a-4c53-bc6e-9ddba84bd42e@github.com>
 <mN__lEll2Wdwg-Xvqnhwbf3Zemi459wCsYtp6vyOsb4=.a450e1d5-63c3-472e-bfd0-82665245e309@github.com>
Message-ID: <JZi_dVosyUE8jE0R6K5yR0vGT4BFkIAKQhN_DbHMhyM=.40d2a98b-c0c0-40cb-950a-7662722d7511@github.com>

On Thu, 18 Jan 2024 07:17:20 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1088:
>> 
>>> 1086:     public void putAll(Map<? extends K, ? extends V> m) {
>>> 1087:         if (table != null) {
>>> 1088:             tryPresize(size() + m.size());
>> 
>> Is overflow not an issue here because calling tryPresize with a negative value will invoke tableSizeFor?
>
> When?`tableSizeFor` is?called with?a?negative?value greater?than?`Integer.MIN_VALUE`, it?ll just?return?`+1`:
> https://github.com/openjdk/jdk/blob/ff8cc268fdaaf85299c94088a226b73e7eaf6bdb/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L704-L707
> 
> This?will in?turn cause?`tryPresize` to?do?nothing when?`table` is?already?initialized.

In the worse case with overflow, we may not presize when we would have liked. I'd like to say its an edge case we don't have to cover. The sum of map sizes would have to be 2^31. Not sure if maps ever get this big in practice.

If its a concern, we could do `max(this.size() + m.size(), m.size())`. I feel its unnecessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1459529675

From sspitsyn at openjdk.org  Fri Jan 19 18:43:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 19 Jan 2024 18:43:38 GMT
Subject: RFR: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be
 static [v2]
In-Reply-To: <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
References: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
 <KyBUNC47ypudLolkKVbMY15iUW5xBbekfSsuNy_CDz8=.b9e9fefe-5908-488d-a7f6-45cc011d7b52@github.com>
Message-ID: <j59OHpg_eb51lhWOVKU6XcPz-luZg7AIlERxR8IiWyA=.fce9338a-e873-4bbb-b634-076e53b1ecc5@github.com>

On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
>> The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
>> The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
>> One detail to underline is the intrinsic implementation needs to use the argument #0 instead of #1.
>> 
>> Testing:
>> - The mach5 tiers 1-6 show no regressions
>
> Serguei Spitsyn has updated the pull request with a new target base 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
>  - 8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

Patricio and Alan, thank you a lot for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17298#issuecomment-1900919472

From sspitsyn at openjdk.org  Fri Jan 19 18:43:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 19 Jan 2024 18:43:39 GMT
Subject: Integrated: 8322744: VirtualThread.notifyJvmtiDisableSuspend should be
 static
In-Reply-To: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
References: <K_L7hHI7umxOYHg8RJjsmypMSq5xIJb2sw35ZRJXuGs=.328959ff-12ac-444b-85b4-883e2bcaf707@github.com>
Message-ID: <nED4SxDgP-2Bb6q07cM2sTiZiPjjPFYEBQ6sJ855YRw=.9b2dbaa8-f9a4-4835-a919-186596545ba2@github.com>

On Mon, 8 Jan 2024 07:55:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be static.
> The method disables/enables suspend of the current virtual thread, a no-op if the current thread is a platform thread. It is confusing for this to be an instance method, it should be static to make it clearer that it doesn't change the target thread.
> The notification method `VirtualThread.notifyJvmtiHideFrames` also has to be static as it does not use/need the virtual thread `this` argument.
> One detail to underline is the intrinsic implementation needs to use the argument #0 instead of #1.
> 
> Testing:
> - The mach5 tiers 1-6 show no regressions

This pull request has now been integrated.

Changeset: 8700de66
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8700de66e45b526958c7a2923d43abe2a736d1d2
Stats:     14 lines in 5 files changed: 0 ins; 0 del; 14 mod

8322744: VirtualThread.notifyJvmtiDisableSuspend should be static

Reviewed-by: pchilanomate, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17298

From jbhateja at openjdk.org  Fri Jan 19 19:03:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 19 Jan 2024 19:03:31 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v7]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Modified code comment for clarity.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/3ed6b8bf..b2190fc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17261/head:pull/17261

PR: https://git.openjdk.org/jdk/pull/17261

From jbhateja at openjdk.org  Fri Jan 19 19:03:32 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 19 Jan 2024 19:03:32 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v5]
In-Reply-To: <DM9gvu3g8Wg9l7j3QqORRcTMjj2KEgKqL99sLkLFfWM=.5c842551-ebef-421b-acb7-47ef38424115@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <z_kQ9zJc-owr5nbEVRAtnHa2e1c-g0AQOQnIZFGQVqU=.91ecbb92-5506-4cb1-be0d-b30ef1f3323c@github.com>
 <SnTw-ng6-mZG1ruFS7ZGYiSvDtvmhuxPh4OBQI8czlA=.13834589-7ff1-4849-ae76-c52b7aa5f5fb@github.com>
 <4-XrsvK-2HpBV3neMmQQ5Q1A4FDOAnmyFtCkKKZcf2A=.32df7d9e-e399-4715-a6b5-f3f2e9c77150@github.com>
 <rmE-0addbbzxDGbBwHgtovvwWCx_gxnmlfzKXdyKN4s=.73ef2a3a-ab4a-4b4a-b6a5-20f4e13ed993@github.com>
 <AHfBpticmm-OZyk9vxBwLDdmPoqCdaDXokb-mUrAs40=.68d8ae97-87c1-4738-9599-b92cf5157857@github.com>
 <DM9gvu3g8Wg9l7j3QqORRcTMjj2KEgKqL99sLkLFfWM=.5c842551-ebef-421b-acb7-47ef38424115@github.com>
Message-ID: <c1KwZ19bQSCBjxuY2VavoZep0_zUZelvOdrD1dcMTqo=.9e87398c-6546-439d-bd3c-0a0dcf303da9@github.com>

On Fri, 19 Jan 2024 07:43:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> For long/double each permute row is 32 byte in size, so a shift by 5 to compute row address.
>
> Ah right. Maybe we could say `32byte = 4 long = 4 * 64bit`.
> Because "64bit row" sounds like the whole row is only 64 bit long. It is actually the cells that are 64bits, not the rows!

DONE

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1459568064

From acobbs at openjdk.org  Fri Jan 19 23:30:43 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 19 Jan 2024 23:30:43 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add @implNote to Javadoc for toPattern().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/a9d78c76..36d70b8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From acobbs at openjdk.org  Fri Jan 19 23:34:26 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 19 Jan 2024 23:34:26 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
Message-ID: <USbKLrolMVtWWn7HBuV5iplty0ElR9HOExazD_elq0s=.d50ee2bb-2a07-487d-86d9-661a182cd73c@github.com>

On Fri, 19 Jan 2024 23:30:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implNote to Javadoc for toPattern().

Adding an additional note of explanation here just for the record (this is copied from the CSR):

> We need to ask how do we know it is safe to quote the unquoted curly brace characters in the subformat patterns? If curly braces are not special to the subformat, then quoting them clearly does no harm. So we only need worry about subformat patterns where curly braces are special. But the only subformat pattern strings supported by `MessageFormat` are for `DecimalFormat`, `SimpleDateFormat`, and `ChoiceFormat`, and curly braces are not special for any of these classes, so we're good.
> 
> However, it should be noted that there is some confusing special logic that clouds this question. If the string that results from evaluating a `ChoiceFormat` subformat of a `MessageFormat` contains an opening curly brace, then a new `MessageFormat` is created from that string and evaluated, and _that_ string replaces the original. This behavior doesn't impact how subformats should be quoted, only how their results are interpreted at "run time".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1901291484

From sviswanathan at openjdk.org  Sat Jan 20 00:31:28 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 20 Jan 2024 00:31:28 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v7]
In-Reply-To: <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>
Message-ID: <iXNYLsfLD1GDLw-TTR8jg5FX4KZv8Vf72-Bcv_9pgJ4=.807fe044-8e05-4276-acc1-8693f1bf7f87@github.com>

On Fri, 19 Jan 2024 19:03:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified code comment for clarity.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5305:

> 5303:     // value, this can potentially be used as a blending mask after
> 5304:     // compressing/expanding the source vector lanes.
> 5305:     vblendvps(dst, dst, xtmp, permv, vec_enc, false, xtmp1);

If I am not wrong, the last argument in vblendps can be same as permv. That way we won't need xtmp1. i.e. the vblendps call can be modified as follows:
vblendvps(dst, dst, xtmp, permv, vec_enc, false, permv);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1460080650

From sviswanathan at openjdk.org  Sat Jan 20 00:38:28 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 20 Jan 2024 00:38:28 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v7]
In-Reply-To: <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>
Message-ID: <C0GCLHzu6dFRkgITCpiKmzCn3sn6zAwkF8ZV8xFrYzM=.db59d21f-f4c2-48a8-8ef3-58f92afa6fa7@github.com>

On Fri, 19 Jan 2024 19:03:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified code comment for clarity.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5331:

> 5329:     // value, this can potentially be used as a blending mask after
> 5330:     // compressing/expanding the source vector lanes.
> 5331:     vblendvps(dst, dst, permv, xtmp, vec_enc, false, xtmp1);

Here the last argument in vblendps can be same as xtmp. That way we won't need xtmp1. i.e. the vblendps call can be modified as follows:
vblendvps(dst, dst, permv, xtmp, vec_enc, false, xtmp);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1460083068

From sviswanathan at openjdk.org  Sat Jan 20 01:18:29 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 20 Jan 2024 01:18:29 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v7]
In-Reply-To: <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <F5wJIq1biThANm-V8yGJkK33wH8Qy-XVPZwq8MwkrSM=.eb7028b9-289a-400b-8971-d1b8cae04df0@github.com>
Message-ID: <x2paAW9C9pxQ-_gw1RiFbm2eVPlsgNwcf2tDmZqm-K4=.c72d7df2-397f-4838-9fed-a514f0537027@github.com>

On Fri, 19 Jan 2024 19:03:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified code comment for clarity.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 985:

> 983:       for (int j = 0; j < 4; j++) {
> 984:         if (mask & (1 << j)) {
> 985:           __ emit_data64(j, relocInfo::none);

This could be something like __ emit_data(2*j, relocInfo::none); __ emit_data(2*j+1, relocInfo::none) to have the double word masks in the table to begin with.
Then we don't need the extra instructions in  vector_compress_expand_avx2() to generate double word permute masks from long masks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1460113427

From jbhateja at openjdk.org  Sat Jan 20 09:55:45 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 20 Jan 2024 09:55:45 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v8]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <nwMMHGrRLsstg6Fbi-ZeFKZFrpu_kn-uo_nMalUd52M=.15c93d29-0506-4671-b154-9879cc56a3c4@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/b2190fc7..cd912308

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=06-07

  Stats: 89 lines in 4 files changed: 20 ins; 50 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17261/head:pull/17261

PR: https://git.openjdk.org/jdk/pull/17261

From forax at univ-mlv.fr  Sat Jan 20 16:40:09 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 20 Jan 2024 17:40:09 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
Message-ID: <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Thursday, January 18, 2024 5:14:38 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>> both gatherers keep it sorted.

> That is unfortunately not the case. That would presume that you can implement
> the composition such that it can preserve all the common flags. Some flags
> could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case. 
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL. 

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag). 
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3. 
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics 

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised). 

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor). 

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED. 

public static int toOpFlags ( int characteristics ) { 
return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) & STREAM_OP_MASK ; 
} 

see below for a full script. 

>> I suppose that if those flags already exist, it's because they have a purpose
>> and i do not understand how it can make the other operations slower.

> Extra invocations, extra storage, and extra composition overhead is not free.
> Since Stream is one-shot you need to include the construction cost with the
> execution cost. For something like an empty Stream construction cost scan be
> 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too. 

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code. 

> Cheers,
> ?

regards, 
R?mi 

--- 
public class GathererFlag { 
// cut and paste from StreamOpFlag 
/** 
* The bit pattern for setting/injecting a flag. 
*/ 
private static final int SET_BITS = 0b01 ; 

/** 
* The bit pattern for clearing a flag. 
*/ 
private static final int CLEAR_BITS = 0b10 ; 

/** 
* The bit pattern for preserving a flag. 
*/ 
private static final int PRESERVE_BITS = 0b11 ; 

private static int position ( int opFlagSet ) { 
return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ; 
} 

private static final int DISTINCT_POSITION = position ( StreamOpFlag . IS_DISTINCT ); 
private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED ); 
private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED ); 

private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag . IS_SHORT_CIRCUIT ); 
private static final int STATELESS_POSITION = 14 ; 
private static final int PARELLIZABLE_POSITION = 15 ; 

public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1 ); 
public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 ); 
public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 ); 

public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 ); 
public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 ); 
public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 ); 

private static final int SHORT_CIRCUIT_MASK = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 ); 

// no GREEDY here 
private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ; 

private static final int STREAM_OP_MASK = 
(( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) | 
GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ; 

public static String toString ( int characteristics ) { 
return Stream . of ( characteristics ) 
.< String >mapMulti(( f , consumer ) -> { 
if (( f & PARELLIZABLE ) == PARELLIZABLE ) { 
consumer .accept( "PARELLIZABLE" ); 
} 
if (( f & STATELESS ) == STATELESS ) { 
consumer .accept( "STATELESS" ); 
} 
if (( f & GREEDY ) == GREEDY ) { 
consumer .accept( "GREEDY" ); 
} 
if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) { 
consumer .accept( "KEEP_DISTINCT" ); 
} 
if (( f & KEEP_SORTED ) == KEEP_SORTED ) { 
consumer .accept( "KEEP_SORTED" ); 
} 
if (( f & KEEP_SIZED ) == KEEP_SIZED ) { 
consumer .accept( "KEEP_SIZED" ); 
} 
}) 
.collect( Collectors . joining ( ", " )); 
} 

public static int toOpFlags ( int characteristics ) { 
return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) & STREAM_OP_MASK ; 
} 

public static String toOpFlagsString ( int opFlags ) { 
return Arrays . stream ( StreamOpFlag . values ()) 
.map( op -> { 
if ( op .isPreserved( opFlags )) { 
return "preserved " + op ; 
} 
if ( op .isCleared( opFlags )) { 
return "cleared " + op ; 
} 
if ( op .isKnown( opFlags )) { 
return "set " + op ; 
} 
return "?? " + op ; 
}) 
.collect( Collectors . joining ( ", " )); 
} 

void main () { 
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ; 
System . out .println( toOpFlagsString ( toOpFlags ( characteristics ))); 

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ; 
System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 ))); 
} 
} 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Thursday, 18 January 2024 16:17
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Thursday, January 18, 2024 3:36:07 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>> others will want to be able to have INJECT-flags, and then people might have
>> different opinions w.r.t. the default should be to clear all flags etc.

>> And that's even before one looks at the composition-part of it, what are the
>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>> set of flags always approaches 0)

>> I spent quite a bit of time on this and in the end tracking all this info, and
>> making sure that the flags of implementations correspond to the actual
>> behavior, just ended up costing performance for most streams and introduced an
>> extra dimension to creation and maintenance which I had a hard time justifying.

> It can be a slippery slope if we were designing from the ground up but the
> stream implementation already exists and SORTED, DISTINCT and SIZED are the
> flags that are already tracked by the current implementation.

> Currently only SHORT_CIRCUIT is set (if not greedy),
> see [
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
> ]

> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
> both gatherers keep it sorted.

>> Making specific, rare, combinations of operations faster at the expense of
>> making 99% of all others slower is a hard pill for most to swallow.

> I suppose that if those flags already exist, it's because they have a purpose
> and i do not understand how it can make the other operations slower.

>> Cheers,
>> ?

> regards,
> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Thursday, 18 January 2024 10:28
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>
>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> Hi R?mi,

>>> You can find some of my benches here: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>> |
>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>> ]

>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>> didn't end up worth it when looking at the bench results over a wide array of
>>> stream sizes and number of operations.

>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>> KEEP_DISTINCT and KEEP_SIZED,
>> all of them say that if the stream was sorted/distinct/sized then the stream
>> returned by a call to gather() is still sorted (with the same comparator),
>> distinct or sized.

>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>> windowFixed is KEEP_DISTINCT.

>> [CC Paul, so he can correct me if i'm saying something stupid]

>> Now for the benchmarks, it depends what you want to measure, benchmarking
>> streams is tricky. This is what i know about benchmarking streams.
>> First, the JIT has two ways to profile types at runtime,
>> Either a method takes a function as parameter
>> void map(Function function) {
>> function.apply(...)
>> }
>> and when map is called with a subtype of Function, the JIT will propagate the
>> exact type when map is inlined,
>> Or a method use a field
>> class Op {
>> Function function;

>> void map() {
>> function.apply(...)
>> }
>> }
>> in that case, the VM records the profile of function.apply() and if there are
>> more than two different profiles, the VM declare profile poluttion and do not
>> try to optimize.

>> The Stream implementation tries very hard to use only parameters instead of
>> fields, that's why it does not use classical Iterator that are pull iterator (a
>> filter iterator requires a field) but a Spliterator which is a push iterator,
>> the element is sent as parameter of the consumer.That's also why collect does
>> not use the builder pattern (that accumulate values in fields) but a Collector
>> that publish the functions to be called as parameter.

>> Obvisously, this is more complex than that, a Collector stores the functions in
>> fields so it should not work well but the implementation uses a record that
>> plays well with escape analysis. Escape analysis see the fields of an instance
>> as parameters so the functions of a Collector are correctly propagated (if the
>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>> are routinely fully inlined with the intermediate operation of a stream.

>> In your tests, i've not seen comparaisons between an existing method like map()
>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>> where the characteristics KEEP_* have an impact and their equivalent using a
>> Gatherer.

>>> Cheers,
>>> ?

>> regards,
>> R?mi

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>> <forax at univ-mlv.fr>
>>> Sent: Wednesday, 17 January 2024 16:48
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: Gatherer: spliterator characteristics are not propagated
>>> While doing some benchmarking of the Gatherer API, i've found that the
>>> characteristics of the spliterator was not propagated by the method
>>> Stream.gather() making the stream slower than it should.

>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>> that this intermediate operation keep the size, which is important if the
>>> terminal operation is toList() because if the size is known, toList() will
>>> presize the List and avoid the creation of an intermediary ArrayList.

>>> See [
>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>> |
>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>> ]

>>> I think that adding a way to propagate the spliterator characteristics through a
>>> Gatherer would greatly improve the performance of commons streams (at least all
>>> the ones that end with a call to toList).

>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>> something and if improving the performance is something worth changing the API.

>>> regards,
>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240120/60b0c76a/attachment-0001.htm>

From stsypanov at openjdk.org  Sat Jan 20 17:29:29 2024
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 20 Jan 2024 17:29:29 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v6]
In-Reply-To: <ZcEkUGVaklPTLkHo8X147Mpt5-9kHIgYpIUHL1Hr3mM=.419e2246-e7a6-48f7-a114-1c34d50d6200@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <ZcEkUGVaklPTLkHo8X147Mpt5-9kHIgYpIUHL1Hr3mM=.419e2246-e7a6-48f7-a114-1c34d50d6200@github.com>
Message-ID: <F1n175IGqzp7GgaXBfBJvn1XFPMu1NccIjkOUKfUrFE=.df215866-78a5-4e51-b516-fac043d814ca@github.com>

On Fri, 22 Dec 2023 13:00:11 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/record-equals' into record-equals
>  - 8322292: Add test case

Anything else I can do about it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1902184686

From jbhateja at openjdk.org  Sun Jan 21 06:55:43 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 21 Jan 2024 06:55:43 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11]
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: <JOTMzJHXX6Lj9sEMj1-WspqmIcI-5wFkpDSGYISaGTU=.2b23d689-d1e5-4ca6-a9cb-ad32b896ff31@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:

  Review comments resolutions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16354/files
  - new: https://git.openjdk.org/jdk/pull/16354/files/de47076e..9ed6b502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=09-10

  Stats: 58 lines in 1 file changed: 18 ins; 15 del; 25 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 duke at openjdk.org  Sun Jan 21 13:37:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 21 Jan 2024 13:37:42 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v15]
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: <wYWh6FksUNtKJncHm92LKf83bw1N6nz4fHGaAEQV5g8=.965a67c2-ad10-4069-b7d1-a13ac329f6ac@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 19 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1
 - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1
 - 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
 - ... and 9 more: https://git.openjdk.org/jdk/compare/a474b372...fa5bddc7

-------------

Changes: https://git.openjdk.org/jdk/pull/16006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=14
  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 duke at openjdk.org  Sun Jan 21 13:48:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 21 Jan 2024 13:48:49 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
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: <NtzCb4RxKc8RQG94yF0uT-QeSzm0TWrLNqx308X_SI4=.0adb5b51-a213-4a13-8ba1-4368c5a9f427@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 41 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_for_string_format
 - 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
 - ... and 31 more: https://git.openjdk.org/jdk/compare/cf67048e...a5f1a4f7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/9618d61d..a5f1a4f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=05-06

  Stats: 43537 lines in 1227 files changed: 26166 ins; 11791 del; 5580 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 alanb at openjdk.org  Sun Jan 21 18:31:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 Jan 2024 18:31:26 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v2]
In-Reply-To: <fSoO4ET48YhP9ynVaTqNT0QynMmsprbyFOY0uKTjrks=.a4c6df1f-8208-4453-b005-4f36709f3c84@github.com>
References: <lGB39UBRJGughgPbl5vd2tr3iNA0zKWL1sesjuPRHW0=.ba906778-881c-47b5-83c8-d0304a7f85d7@github.com>
 <wcsC62NBwXxSao82f-ZWLcAypLbRnUfduueKx_eTqgU=.af9f1bcc-7240-4de5-af5b-357b246f2763@github.com>
 <ZMOlv7WsZx6RowkT5cnuf06CXKkVAcFrPcCpPZvOHS8=.f6f2e11d-a869-405e-ab32-3c25ead0bdd5@github.com>
 <fSoO4ET48YhP9ynVaTqNT0QynMmsprbyFOY0uKTjrks=.a4c6df1f-8208-4453-b005-4f36709f3c84@github.com>
Message-ID: <CYo79kVuw8QZ0KIMZUAaX65NOcX0ewbWCrEnCz-qDRA=.994780d2-a2fd-4700-b6c7-fb9d08a1a4a0@github.com>

On Fri, 19 Jan 2024 08:17:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Do you want to keep it then or should I open an RFE to remove it?

Maybe leave it for now as there is significant churn in this code right now, with more accumulating in the loom repo in advance of the monitors work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1902720581

From ethan at mccue.dev  Sun Jan 21 20:18:09 2024
From: ethan at mccue.dev (Ethan McCue)
Date: Sun, 21 Jan 2024 15:18:09 -0500
Subject: Does anyone have context on jdk.httpserver?
Message-ID: <CA+NR86g2=4XqxEw9Cqwvsa6=mBObA8xRv8fNDSdJkzAH03=Cpg@mail.gmail.com>

Hi all,

Elliot[1] and I have been digging into the HTTP(S) server implementation
provided by the jdk.httpserver module.

It hasn't taken long to notice that the provided implementation
is...lacking. Both in performance, as it places extremely low and errors
out on benchmarks [2][3], and in polish, as doing relatively simple tasks
like printing out the result of HttpExchange#getRequestHeaders() does not
actually include the headers in the output.

But, the actual API isn't wretched. The overall design (with a Filter chain
and a mutable "out" object for responses) is reminiscent of Servlets and
there is an SPI hook to provide custom server implementations. And unlike
the jwebserver tool, which is built on this, there isn't a "for education
purposes only" sign anywhere and it is part of an exported and supposedly
supported module.

All that is to ask - does anyone on this mailing list have any historical
context on this? Why was it added to the JDK, what were the goals of its
implementation, are there any records of the decision process behind its
design?

Separately is there any appetite for improving the performance of the
built-in server implementation?


[1]: https://github.com/ebarlas/microhttp
[2]:
https://www.techempower.com/benchmarks/#hw=ph&test=plaintext&section=data-r22
[3]:
https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Java/httpserver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240121/960ed173/attachment.htm>

From jbhateja at openjdk.org  Mon Jan 22 07:11:30 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 Jan 2024 07:11:30 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
Message-ID: <Xb-U-_Ct_L7a8Liky0c4TCbhoFUfcnPIsn-xZ6RZdQA=.034ae95a-54e7-4497-a570-4d7a48676bd1@github.com>

On Thu, 11 Jan 2024 23:06: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 with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'openjdk:master' into indexof
>  - Merge branch 'openjdk:master' into indexof
>  - Addressing review comments.
>  - Fix for JDK-8321599
>  - Support UU IndexOf
>  - Only use optimization when EnableX86ECoreOpts is true
>  - Fix whitespace
>  - Merge branch 'openjdk:master' into indexof
>  - Comments; added exhaustive-ish test
>  - Subtracting 0x10 twice.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 505:

> 503:     __ cmpb(Address(rbx, r15, Address::times_1, -0xa), rax);
> 504:     __ jne(L_top_loop_1);
> 505:     __ jmp(L_0x406019);

Instead of having special handling for each tail size (3 - 31 bytes), can we directly use 32 bytes VMASKMOVPS with appropriate mask for different tail sizes and only residual part (0 - 3 bytes) can fall over to scalar tail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1461424231

From jbhateja at openjdk.org  Mon Jan 22 07:11:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 Jan 2024 07:11:31 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <Xb-U-_Ct_L7a8Liky0c4TCbhoFUfcnPIsn-xZ6RZdQA=.034ae95a-54e7-4497-a570-4d7a48676bd1@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <Xb-U-_Ct_L7a8Liky0c4TCbhoFUfcnPIsn-xZ6RZdQA=.034ae95a-54e7-4497-a570-4d7a48676bd1@github.com>
Message-ID: <UynYzpbWaDK6yKJz0BnjHT90NiW6DbRGM3O5NeZfovQ=.4fec6216-656a-49fe-a806-b738daed5b89@github.com>

On Mon, 22 Jan 2024 07:05:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 505:
> 
>> 503:     __ cmpb(Address(rbx, r15, Address::times_1, -0xa), rax);
>> 504:     __ jne(L_top_loop_1);
>> 505:     __ jmp(L_0x406019);
> 
> Instead of having special handling for each tail size (3 - 31 bytes), can we directly use 32 bytes VMASKMOVPS with appropriate mask for different tail sizes and only residual part (0 - 3 bytes) can fall over to scalar tail.

Basically tail size can be rounded to nearest multiple of doubleword.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1461425962

From Alan.Bateman at oracle.com  Mon Jan 22 07:18:24 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Jan 2024 07:18:24 +0000
Subject: Does anyone have context on jdk.httpserver?
In-Reply-To: <CA+NR86g2=4XqxEw9Cqwvsa6=mBObA8xRv8fNDSdJkzAH03=Cpg@mail.gmail.com>
References: <CA+NR86g2=4XqxEw9Cqwvsa6=mBObA8xRv8fNDSdJkzAH03=Cpg@mail.gmail.com>
Message-ID: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com>

On 21/01/2024 20:18, Ethan McCue wrote:
> Hi all,
>
> Elliot[1] and I have been digging into the HTTP(S) server 
> implementation provided by the jdk.httpserver module.
>
> It hasn't taken long to notice that the provided implementation 
> is...lacking. Both in performance, as it places extremely low and 
> errors out on benchmarks [2][3], and in polish, as doing relatively 
> simple tasks like printing out the result of 
> HttpExchange#getRequestHeaders()?does not actually include the headers 
> in the output.
>
> But, the actual API isn't wretched. The overall design (with a Filter 
> chain and a mutable "out" object for responses) is reminiscent of 
> Servlets and there is an SPI hook to provide custom server 
> implementations. And unlike the jwebserver tool, which is built on 
> this, there isn't a "for education purposes only" sign anywhere and it 
> is part of an exported and supposedly supported module.
>
> All that is to ask - does anyone on this mailing list have any 
> historical context on this? Why was it added to the JDK, what were the 
> goals of its implementation, are there any records of the decision 
> process behind its design?
>
> Separately is there any appetite for improving the performance of the 
> built-in server implementation?

The history on this is the web services client (meaning JAX-WS), added 
in Java 6. A HTTP server was required to support web services "callbacks".

As it turned out, having a basic HTTP server in the JDK is very useful 
for writing tests and very useful at reducing the "getting startup" 
effort to serve up a web page. The HTTP server was never meant to be 
feature rich with performance on par with other HTTP servers. However, 
it does have a service provider interface (SPI) so alternative 
implementations can be used (there are at least 3 full featured HTTP 
servers that implement the SPI).

More recently, JEP 408 [1] added a command line interface to make it 
easy to get started. It also added to the API to make it easy to create 
and customize. You've found that so you have some context on what the 
HTTP server is intended for now.

The net-dev mailing list is the mailing list to use.

-Alan

[1] https://openjdk.org/jeps/408



From shade at openjdk.org  Mon Jan 22 08:33:27 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Jan 2024 08:33:27 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
Message-ID: <PNWyx7wG_Am6HhYpK2xyu5LlHfqT2EfsOkxhc_jROEo=.147c40ae-c546-4471-8f29-8e408e506e1c@github.com>

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
> 
> I provisionally call this flag `external-dep`, but I am open for other suggestions.
> 
> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
> 
> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
> 
> Additional testing:
>  - [x] `make test TEST=applications/` fails
>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests

Any takers? Maybe the audience should include core-libs too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1903486053

From duke at openjdk.org  Mon Jan 22 08:54:39 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 08:54:39 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v2]
In-Reply-To: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
References: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
Message-ID: <hy5TfhHxLgs5ws-tXG_zAT0_54_cdsIDEMkrNEzcOyI=.d1976ed7-4890-4658-9881-a7fa2d3b145c@github.com>

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

sendaoYan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
  
  Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17386/files
  - new: https://git.openjdk.org/jdk/pull/17386/files/e8a99fe4..9f0aa2a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17386&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17386&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17386/head:pull/17386

PR: https://git.openjdk.org/jdk/pull/17386

From Alan.Bateman at oracle.com  Mon Jan 22 09:08:19 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Jan 2024 09:08:19 +0000
Subject: Does anyone have context on jdk.httpserver?
In-Reply-To: <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com>
References: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com>
 <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com>
Message-ID: <e163890a-8301-4a34-997f-1eb0d17de27d@oracle.com>

On 22/01/2024 08:43, Robert Engels wrote:
> See github.com/robaho/httpserver  for a more capable fork of the JDK code.
>
> Would love to create a PR to move the core changes back into the JDK but the net-dev folks don?t seem to be interested

As I recall, it wasn't really possible to do any assessment because the 
"contribution" wasn't covered by the OCA. In addition, I think you said 
in one of the mails that it includes code from another project (for 
websocket or HTTP upgrade?) and it's a big deal to have to import and 
work through the license issues with 3rd party code.

At a high level it seems reasonable to update the HTTP server 
implementation to work better with virtual threads but updating it to be 
a more fully featured HTTP server goes beyond what this HTTP server 
was/is intended for.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240122/49670b27/attachment-0001.htm>

From duke at openjdk.org  Mon Jan 22 09:26:36 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 09:26:36 GMT
Subject: Withdrawn: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
References: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
Message-ID: <zOHY3r1ICvZvzpy6JlunWBc0Gs5KTdPPhD8Jp8ycULo=.e890fed3-6115-4c9d-9155-0e0e9b164803@github.com>

On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17386

From duke at openjdk.org  Mon Jan 22 09:39:52 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 09:39:52 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
Message-ID: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>

8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

-------------

Commit messages:
 - 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

Changes: https://git.openjdk.org/jdk/pull/17514/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17514&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323640
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17514/head:pull/17514

PR: https://git.openjdk.org/jdk/pull/17514

From duke at openjdk.org  Mon Jan 22 09:39:52 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 09:39:52 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <pYkGoKqK_pO_Qgtv8bJvUlf-7hehohjedkl83eqrB9U=.a0b2b486-9d46-4805-95e0-f4e25ebd0c7b@github.com>

On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

The test case before this PR has a maximum heap of 64MB and applies for 8M of memory each time in the for loop. When applying for memory for the sixth time, it was killed by the docker container because of OOM, jdk.internal.platform.Metrics.systemMetrics().getMemoryFailCount( ) interface has no chance to return 1, and the Java process returns exit code 137. The maximum heap is also 64M, The PR is changed to 1KB each time to ensure that the getMemoryFailCount() interface has a chance to return 1 and the test case has a chance to exit the for loop of memory allocation.

## test result before this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/4554dd00-6da5-4529-907a-45e2df5c902b)


## test result after this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/32ea4fc8-aa04-425e-8481-a920265d2b1f)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1903589872

From abimpoudis at openjdk.org  Mon Jan 22 09:41:50 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 Jan 2024 09:41:50 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v39]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <tIMzgb8MpIXtlaYUmDKBNDD2Pb-l4Bortd9LLIIfCX0=.d09d1b72-4068-42f0-a5a5-56a89417a59b@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 56 commits:

 - Update copyright year, javadoc, JDK version
 - Merge branch 'master' into primitive-patterns
 - 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
 - ... and 46 more: https://git.openjdk.org/jdk/compare/9049402a...676af9de

-------------

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=38
  Stats: 3281 lines in 41 files changed: 3000 ins; 110 del; 171 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 Jan 22 10:48:05 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 Jan 2024 10:48:05 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v40]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <3q3UXhPplqk5X8E0rnHuEyUFY-HiAIQSYPgBJeIXzEE=.bcc70cff-e2da-471b-abea-7ed23d168e18@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 two additional commits since the last revision:

 - Update ExactConversionsSupport Javadoc and JDK version
 - Revert "Update copyright year, javadoc, JDK version"
   
   This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/676af9de..ed61d5fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=38-39

  Stats: 27 lines in 27 files changed: 0 ins; 0 del; 27 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 jkratochvil at openjdk.org  Mon Jan 22 12:52:45 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 22 Jan 2024 12:52:45 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v3]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <ikaCVGE3lkLglXB5eHw6yLLW3QfIFw7QQrgXq_Dw1g0=.a20c4e7d-afe7-4ad4-8be4-c496223aeee4@github.com>

> The testcase requires root permissions.

Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into master-cgroup
 - Fix gtest testcases compilation errors
 - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected
 - 4c556a78: <no commit message found>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/395ef61f..ae58f7e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=01-02

  Stats: 44851 lines in 1274 files changed: 27136 ins; 11937 del; 5778 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 eirbjo at openjdk.org  Mon Jan 22 13:58:00 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 22 Jan 2024 13:58:00 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v5]
In-Reply-To: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
Message-ID: <w5PXuvJGO6yO4zPtQGuG9zmsZ8vrvE1j72r1ZqTJFeQ=.9ed8a042-fc16-47fc-ab13-262761928fc9@github.com>

> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once.
> 
> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets.
> 
> This fix is to move the closing of the wrapped stream inside the finally block.
> 
> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?)
> 
> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification:  *Writes remaining compressed data to the output stream and closes the underlying stream.*
> 
> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification.
> 
> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Spell out what is checked by each test instead of using the word "correct"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17209/files
  - new: https://git.openjdk.org/jdk/pull/17209/files/96deca07..39a14de3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17209&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17209&range=03-04

  Stats: 40 lines in 1 file changed: 33 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17209/head:pull/17209

PR: https://git.openjdk.org/jdk/pull/17209

From eirbjo at openjdk.org  Mon Jan 22 14:04:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 22 Jan 2024 14:04:33 GMT
Subject: RFR: 8313739: ZipOutputStream.close() should always close the
 wrapped stream [v4]
In-Reply-To: <g0Pykby5TiC7DYgoY237UvcrgaMWlVuXqV4EF5GxlJg=.2cd923e3-cbd5-4e0e-bb7b-71e5b1ca8578@github.com>
References: <pTmvVnKJCpbNeyRPusgrUZYjKxzah-uZG9ig_a7nF0s=.cb6ce43c-94f7-4ae9-b166-703e066d25ea@github.com>
 <Airpkbb74hed7sPRNLTr7uVs5Qon5SNKCfDjMYyGJHY=.d2d39b82-4ddf-4511-898c-de0c48318277@github.com>
 <g0Pykby5TiC7DYgoY237UvcrgaMWlVuXqV4EF5GxlJg=.2cd923e3-cbd5-4e0e-bb7b-71e5b1ca8578@github.com>
Message-ID: <-cE9koQ4yoMQHY3D_d8sozfj3gqCOKq9-DDVa5VCYmM=.0758e900-d716-42dd-af44-2253c992a4e6@github.com>

On Tue, 16 Jan 2024 18:18:38 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This comment could use a bit of wordsmithing to indicate what "correct" means

It's hard to write good prose for these tricky error scenarios. But just saying "correct" without defining it is a bit too lazy, yes :-)

Please take a look at the last commit 39a14de where I've expanded "correct" in the test comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17209#discussion_r1461905312

From eirbjo at openjdk.org  Mon Jan 22 14:37:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 22 Jan 2024 14:37:35 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <ga90hOxKqdOMq97zdDfeobco2FXuQOjF-Pdfn4jhgVU=.28131301-7ca6-48b7-8e7f-444fc3994d87@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <33U0s06xG2FNIDYsaZ0oPOnF1uoZUw4cwZgpY1AYrhI=.4d6e8dc7-8cba-41f0-bd8b-252d64e810fb@github.com>
 <guU5N9ppbMKZvGppayMCoUAAlxGiSt7cTs71d9I40HE=.43440217-73fc-431f-9da9-8268d15ad805@github.com>
 <ga90hOxKqdOMq97zdDfeobco2FXuQOjF-Pdfn4jhgVU=.28131301-7ca6-48b7-8e7f-444fc3994d87@github.com>
Message-ID: <L_P2PB_bBvzFyQVyRnjayW-qHrMax6U_pfj3-Xl90mI=.7e7d68b8-0a12-4049-ada8-34d4a9a99701@github.com>

On Tue, 16 Jan 2024 14:55:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I think the only role that a zip64 block should play when we are deciding how to parse a data descriptor is whether or not the entry has zip64 extra field set (the header id value of the extra field). Does that sound reasonable?

Are you suggesting that we ONLY look for the presence of a Zip64 (tag 0x1) extended field? Meaning we should ignore the following:

- The values of the 'compressed size' and 'uncompressed size' fields in the LOC header
- The contents/fields in the data block in the Zip64 header

The purpose of this check is to determine wheter the entry "is in the ZIP64 format", to use parlance from `APPNOTE.TXT`. The reason stronger validation was added was to avoid false positives, meaning an entry would be interpreted as "in the Zip64 format", even when that was not the intention of the producer. Some of this validation was on my initiative, but I think maybe some was in response to concerns raised in review.

If we ignore the 'uncompressed size' and 'compresssed size' fields, then if a LOC has both of these set to zero and has a Zip64 extended field, then we'll intepret this as "in the Zip64 format", even though no field is marked using the Zip64 magic value `0xFFFFFFFF`.

I think I would be fine with dropping inspection of the Zip64 contents (as there are probably efforts underway to add validation of LOC Zip64 fields similar to the recently added CEN validation).

But I'm a bit worried that ignoring the LOC values will make us parse some data descriptors using 8 bytes, when the producer did in fact not intend to use the Zip64 format. (The Zip64 field just came through some kind of "pollution" or unintended copying.

A natural way to implement Zip64 parsing is to only look at the extended field if at least one of the relevant LOC headers are `0xFFFFFFFF`, otherwise one can short-circuit and assume there is no Zip64 field.

@LanceAndersen Do you have a cent or two to spare?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1461951695

From sgehwolf at openjdk.org  Mon Jan 22 15:06:29 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 22 Jan 2024 15:06:29 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <LrIsvPuptlg6kpZIiEg2al4DO1sMxtQFcY-iOXx_5mg=.53e24cae-bd26-4c11-babb-a582d0971f13@github.com>

On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

`1k` increments for a total of `512k` times seems overkill. Are you sure that's needed to make the test pass? How about `1MB` increments for a total of `512` times?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17514#pullrequestreview-1836685784

From rgiulietti at openjdk.org  Mon Jan 22 15:17:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 22 Jan 2024 15:17:29 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
Message-ID: <TSzOsp4-E2zsFwGSsnNf_fG5-5R_VfdYOu68yjMrZ8I=.16bd31bf-0d7e-4442-aff4-31b7779bed96@github.com>

On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespaces

The test does not seem to check that the results are correct, but just measures elapsed time.

For this, in the context of the OpenJDK, we use [JMH](https://github.com/openjdk/jmh) for performance benchmarks. It avoids all the common issues with less sophisticated approaches. At first, it might seem harder to use, but it is more reliable than ad-hoc measurements. While not perfect, it has established itself as the "golden standard", so to say.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904217509

From viktor.klang at oracle.com  Mon Jan 22 15:22:11 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 22 Jan 2024 15:22:11 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi R?mi,

For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588

So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.


public static int toOpFlags(int characteristics) {
  return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---

public class GathererFlag {
  // cut and paste from StreamOpFlag
  /**
   * The bit pattern for setting/injecting a flag.
   */
  private static final int SET_BITS = 0b01;

  /**
   * The bit pattern for clearing a flag.
   */
  private static final int CLEAR_BITS = 0b10;

  /**
   * The bit pattern for preserving a flag.
   */
  private static final int PRESERVE_BITS = 0b11;


  private static int position(int opFlagSet) {
    return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
  }

  private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
  private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
  private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

  private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
  private static final int STATELESS_POSITION = 14;
  private static final int PARELLIZABLE_POSITION = 15;

  public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
  public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
  public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

  public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
  public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
  public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

  private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

  // no GREEDY here
  private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

  private static final int STREAM_OP_MASK =
      ((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
      GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

  public static String toString(int characteristics) {
    return Stream.of(characteristics)
        .<String>mapMulti((f, consumer) -> {
          if ((f & PARELLIZABLE) == PARELLIZABLE) {
            consumer.accept("PARELLIZABLE");
          }
          if ((f & STATELESS) == STATELESS) {
            consumer.accept("STATELESS");
          }
          if ((f & GREEDY) == GREEDY) {
            consumer.accept("GREEDY");
          }
          if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
            consumer.accept("KEEP_DISTINCT");
          }
          if ((f & KEEP_SORTED) == KEEP_SORTED) {
            consumer.accept("KEEP_SORTED");
          }
          if ((f & KEEP_SIZED) == KEEP_SIZED) {
            consumer.accept("KEEP_SIZED");
          }
        })
        .collect(Collectors.joining(", "));
  }

  public static int toOpFlags(int characteristics) {
    return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240122/542e3e84/attachment-0001.htm>

From duke at openjdk.org  Mon Jan 22 15:36:27 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 15:36:27 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <TSzOsp4-E2zsFwGSsnNf_fG5-5R_VfdYOu68yjMrZ8I=.16bd31bf-0d7e-4442-aff4-31b7779bed96@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <TSzOsp4-E2zsFwGSsnNf_fG5-5R_VfdYOu68yjMrZ8I=.16bd31bf-0d7e-4442-aff4-31b7779bed96@github.com>
Message-ID: <qNTTwNPLdSK2U3YwesaljXW1GEMGkrF2yObSCoZtE68=.9847c8f2-c565-4cee-ab52-5fa86607a041@github.com>

On Mon, 22 Jan 2024 15:14:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespaces
>
> The test does not seem to check that the results are correct, but just measures elapsed time.
> 
> For this, in the context of the OpenJDK, we use [JMH](https://github.com/openjdk/jmh) for performance benchmarks. It avoids all the common issues with less sophisticated approaches. At first, it might seem harder to use, but it is more reliable than ad-hoc measurements. While not perfect, it has established itself as the "golden standard", so to say.

@rgiulietti The correctness of the algorithm simply follows by the fact that it is just a particularization of `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904256641

From rgiulietti at openjdk.org  Mon Jan 22 15:40:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 22 Jan 2024 15:40:31 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
Message-ID: <xz7dAVf6RGCbJbNq82fk1ZqS97wPmssSRjSydgCXDTc=.1d2aca58-bfae-4d58-896e-321b7c24bd48@github.com>

On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespaces

Sure. But the purpose of a test is not much to check the _current_ code but to protect against erroneous changes in the future. Without a test, a later modification might introduce an undetected regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904265345

From duke at openjdk.org  Mon Jan 22 15:47:28 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 15:47:28 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <xz7dAVf6RGCbJbNq82fk1ZqS97wPmssSRjSydgCXDTc=.1d2aca58-bfae-4d58-896e-321b7c24bd48@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <xz7dAVf6RGCbJbNq82fk1ZqS97wPmssSRjSydgCXDTc=.1d2aca58-bfae-4d58-896e-321b7c24bd48@github.com>
Message-ID: <oXh1F4d5ur-xqXF4lfWWYC_2FKcDNggNP6jx8_CLJRU=.f3e86005-a46d-473e-8f93-7a86594f2535@github.com>

On Mon, 22 Jan 2024 15:38:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespaces
>
> Sure. But the purpose of a test is not much to check the _current_ code but to protect against erroneous changes in the future. Without a test, a later modification might introduce an undetected regression.

@rgiulietti The method `MutablebigInteger.divWord(long, int)` is used for division of BigIntegers, and division of BigIntegers already has several tests. Anyway, in case we can use the same tests which already exist for  `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904279676

From duke at openjdk.org  Mon Jan 22 16:03:31 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 16:03:31 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <xz7dAVf6RGCbJbNq82fk1ZqS97wPmssSRjSydgCXDTc=.1d2aca58-bfae-4d58-896e-321b7c24bd48@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <xz7dAVf6RGCbJbNq82fk1ZqS97wPmssSRjSydgCXDTc=.1d2aca58-bfae-4d58-896e-321b7c24bd48@github.com>
Message-ID: <da_TOdaYYPzlARSLVciG3r6eGPzvGR7o0LMXHYmNhZs=.8855ff89-3d7e-4da8-af50-2bffd32a97c2@github.com>

On Mon, 22 Jan 2024 15:38:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespaces
>
> Sure. But the purpose of a test is not much to check the _current_ code but to protect against erroneous changes in the future. Without a test, a later modification might introduce an undetected regression.

@rgiulietti By the way, the tests for correctness of `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)` simply check the consistency between their results and those of `BigInteger.divide(BigInteger)`, so those tests are implicitly tests also for `MutablebigInteger.divWord(long, int)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904311866

From rgiulietti at openjdk.org  Mon Jan 22 16:18:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 22 Jan 2024 16:18:31 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
Message-ID: <PWmilzOsVUNt1RMPIBrn0OPmXHTwCJ-3ycDQ2eFdSfs=.8adc19ab-adb9-406b-bf6f-f2ec0bdf892f@github.com>

On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespaces

What about splitting the result of `divWord()` into its components `q` and `r` and check that `0 <= r < d` and `n == q * d + r`? Mathematically this should be sufficient. Perhaps you might need to take care about unsigned vs signed arithmetic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904341649

From duke at openjdk.org  Mon Jan 22 16:39:29 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 16:39:29 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <PWmilzOsVUNt1RMPIBrn0OPmXHTwCJ-3ycDQ2eFdSfs=.8adc19ab-adb9-406b-bf6f-f2ec0bdf892f@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <PWmilzOsVUNt1RMPIBrn0OPmXHTwCJ-3ycDQ2eFdSfs=.8adc19ab-adb9-406b-bf6f-f2ec0bdf892f@github.com>
Message-ID: <9VAWb14yy9VeXxV6Pk8854Mc4O0Pc3fZsb3gwinBm4w=.fffdb728-5ec8-4346-b4d6-4054aa6ddd18@github.com>

On Mon, 22 Jan 2024 16:15:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespaces
>
> What about splitting the result of `divWord()` into its components `q` and `r` and check that `0 <= r < d` and `n == q * d + r`? Mathematically this should be sufficient. Perhaps you might need to take care about unsigned vs signed arithmetic.

@rgiulietti In this case, the unsigned arithmetic is not a problem, since `(d & LONG_MASK) > 0` and multiplication and addition semantics is equivalent in signed/unsigned integers. Perhaps, it would be better to call directly `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)` to possibly use directly assembly code, since they are annotated as IntrinsicCandidate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904381418

From naoto at openjdk.org  Mon Jan 22 17:18:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Jan 2024 17:18:37 GMT
Subject: Integrated: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <-2FQ8jqCpBpPyZVJxM2TSC2Ka4TTkMBI97jclhIJKUU=.97c56d74-c15f-4a71-8214-ed0a1dc4a011@github.com>

On Thu, 18 Jan 2024 19:37:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

This pull request has now been integrated.

Changeset: 0d8543d6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d8543d6773a516dad54038070dce507179d0709
Stats:     44 lines in 6 files changed: 5 ins; 7 del; 32 mod

8324065: Daylight saving information for `Africa/Casablanca` are incorrect

Reviewed-by: iris, joehw, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/17492

From rgiulietti at openjdk.org  Mon Jan 22 17:26:28 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 22 Jan 2024 17:26:28 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
Message-ID: <G6H8DpHvjt8VXkvetqVnTykceRhdXn3U6VR_8ikCeDQ=.4051f8fb-38cd-444b-b734-e8356f4e4783@github.com>

On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespaces

AFAIK, IntrinsicCandidate methods are only relevant in JIT compiled code. A test that checks correctness might not reach the compilation stage, and execute only in the bytecode interpreter.

But IMO using the result of `divWord()` as suggested is simple enough and avoids hidden dependencies.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904466691

From duke at openjdk.org  Mon Jan 22 17:39:28 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 17:39:28 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <G6H8DpHvjt8VXkvetqVnTykceRhdXn3U6VR_8ikCeDQ=.4051f8fb-38cd-444b-b734-e8356f4e4783@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <G6H8DpHvjt8VXkvetqVnTykceRhdXn3U6VR_8ikCeDQ=.4051f8fb-38cd-444b-b734-e8356f4e4783@github.com>
Message-ID: <zwneqoEiHy9VW5pXb_d8mYF-mfnruqcXIqsh1rHuX8s=.5f22e88d-8f1d-42f6-90d8-79850902ab2b@github.com>

On Mon, 22 Jan 2024 17:23:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> AFAIK, IntrinsicCandidate methods are only relevant in JIT compiled code. A test that checks correctness might not reach the compilation stage, and execute only in the bytecode interpreter.
> 
> But IMO using the result of `divWord()` as suggested is simple enough and avoids hidden dependencies.

@rgiulietti Perhaps I was not clear enough. I'm not intended to use `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)` in the tests, but in the algorithm implementation, instead of using an hard-coded implementation, to use directly the assembly code, although this implies to calculate the approximations of `q` and `r` two times instead of one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904488957

From simonis at openjdk.org  Mon Jan 22 17:57:29 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 Jan 2024 17:57:29 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v3]
In-Reply-To: <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
Message-ID: <KqR1DoTjCohxJZMyc6zOBod4XxbGBjmLmKbRH_cdpYo=.a636b2b6-5747-45f9-9b55-4896ea666e39@github.com>

On Wed, 17 Jan 2024 21:16:02 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> 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%.
>> 
>> ### JMH results for testPutAll (size = 10000)
>> 
>> before patch:
>> 
>> 
>> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>>   4315291.542 ?(99.9%) 336034.190 ns/op [Average]
>>   (min, avg, max) = (3974688.194, 4315291.542, 4871772.209), stdev = 314326.589
>>   CI (99.9%): [3979257.352, 4651325.731] (assumes normal distribution)
>> 
>> 
>> after patch:
>> 
>> 
>> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>>   3006955.723 ?(99.9%) 271757.969 ns/op [Average]
>>   (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev = 254202.573
>>   CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
>> 
>> 
>> Average time is decreased about 30%.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   putAll presize based on sum on both map sizes

Thanks for the latest changes. The patch looks good now, except that I think the benchmark could be made more accurate (see inline comments). This will probably result in an even higher improvement for `putAll()`.

test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:

> 120:     @Benchmark
> 121:     public ConcurrentHashMap<Integer, Integer> testConcurrentHashMapPutAll() {
> 122:         ConcurrentHashMap<Integer, Integer> map = new ConcurrentHashMap<>();

I think this benchmark could be made more accurate by creating the new, temporary map with the right initial size (i.e. `ConcurrentHashMap<>(nkeys)`) to avoid calls to `tryPresize()` in this setup step.

-------------

Changes requested by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17116#pullrequestreview-1837027167
PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1462205109

From rgiulietti at openjdk.org  Mon Jan 22 18:10:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 22 Jan 2024 18:10:27 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
Message-ID: <mpSkVTkg4GONNknaPEvRt-FLJZ0_zFVelkNGfoCzGhM=.c459b64d-b538-4a45-9ff4-214ba10bdbda@github.com>

On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespaces

As you note, that would probably require two divisions. I don't know if the JIT compiler can detect that the arguments are the same and emit just one division instead.
I think your code is good enough for the purpose of [Mutable]BigInteger, and better than the current one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904538746

From duke at openjdk.org  Mon Jan 22 18:14:26 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 18:14:26 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <mpSkVTkg4GONNknaPEvRt-FLJZ0_zFVelkNGfoCzGhM=.c459b64d-b538-4a45-9ff4-214ba10bdbda@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <mpSkVTkg4GONNknaPEvRt-FLJZ0_zFVelkNGfoCzGhM=.c459b64d-b538-4a45-9ff4-214ba10bdbda@github.com>
Message-ID: <2WDSgQsDIbOKSW7Ps2PlYWgi2wfmoSOymxOvChzSK-Y=.7cce7164-8949-4e73-a14c-0ed6be623dbf@github.com>

On Mon, 22 Jan 2024 18:07:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespaces
>
> As you note, that would probably require two divisions. I don't know if the JIT compiler can detect that the arguments are the same and emit just one division instead.
> I think your code is good enough for the purpose of [Mutable]BigInteger, and better than the current one.

@rgiulietti It seems unlikely that the JIT compiler can do that, at least to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904544724

From mchung at openjdk.org  Mon Jan 22 18:42:27 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 22 Jan 2024 18:42:27 GMT
Subject: RFR: 8323835: Updating ASM to 9.6 for JDK 23
In-Reply-To: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
References: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
Message-ID: <Gwvd-qPhq7yxRC42Zsz7zSRbInn8HdrYBEU726GWRtE=.6bee2200-4588-476b-aa0e-61f80de2c256@github.com>

On Tue, 16 Jan 2024 21:18:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Updating ASM to version 9.6,
> 
> Thanks in advance for the reviews,
> Vicente

The change looks okay to me.   Most of the changes are doc change.  I see many files are updated just to remove the empty line at the end of the file - is that intentional, imported from this upgrade?     

Any need to update the copyright header?   The new file CheckFrameAnalyzer.java still has the same copyright header years as other files.  I assume no need then?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17453#issuecomment-1904588248

From abimpoudis at openjdk.org  Mon Jan 22 18:42:56 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 Jan 2024 18:42:56 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@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 60 commits:

 - Improve Javadoc of ExactConversionsSupport
 - Merge branch 'master' into primitive-patterns
 - Update ExactConversionsSupport Javadoc and JDK version
 - Revert "Update copyright year, javadoc, JDK version"
   
   This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.
 - Update copyright year, javadoc, JDK version
 - Merge branch 'master' into primitive-patterns
 - Merge branch 'master' into primitive-patterns
 - Cleanup
 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - ... and 50 more: https://git.openjdk.org/jdk/compare/c9cacfb2...50cb9832

-------------

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=40
  Stats: 3272 lines in 41 files changed: 3008 ins; 110 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 Jan 22 18:52:43 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 18:52:43 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v4]
In-Reply-To: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
Message-ID: <mvrLHlhNJCbdReq6G80wkQlFGecoF1KzULtb87J9Kuw=.47be72d7-a8a5-4afd-b620-1fc0dd0b56d6@github.com>

> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Update TestDivWord.java
  
  Added method to check results of divWord

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17291/files
  - new: https://git.openjdk.org/jdk/pull/17291/files/2460b066..67e3027f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17291&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17291&range=02-03

  Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17291/head:pull/17291

PR: https://git.openjdk.org/jdk/pull/17291

From duke at openjdk.org  Mon Jan 22 18:55:31 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 18:55:31 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v3]
In-Reply-To: <mpSkVTkg4GONNknaPEvRt-FLJZ0_zFVelkNGfoCzGhM=.c459b64d-b538-4a45-9ff4-214ba10bdbda@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <i9LWMjj5cyTQUJEg6O7qyOv-IQaU0rXh14qMbpTK_Do=.5c1e50cf-decc-4887-9a3a-8ed4b58ccb57@github.com>
 <mpSkVTkg4GONNknaPEvRt-FLJZ0_zFVelkNGfoCzGhM=.c459b64d-b538-4a45-9ff4-214ba10bdbda@github.com>
Message-ID: <jYf0bEsR0X4P9LFZvlnpQG78TAdc6aiPto3nkvdNvG0=.5e6013e8-f083-48cf-a182-93a56bbb688c@github.com>

On Mon, 22 Jan 2024 18:07:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespaces
>
> As you note, that would probably require two divisions. I don't know if the JIT compiler can detect that the arguments are the same and emit just one division instead.
> I think your code is good enough for the purpose of [Mutable]BigInteger, and better than the current one.

@rgiulietti I've added a method to check the results of tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1904607454

From forax at univ-mlv.fr  Mon Jan 22 18:56:40 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 22 Jan 2024 19:56:40 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Monday, January 22, 2024 4:22:11 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> Hi R?mi,

Hello, 

> For instance, stateless is neither recessive nor dominant, since the composition
> of two stateless operations is only ever stateless if they both are greedy as
> well: [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
> ]

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough. 

> So even if making it represented as ints (more like Spliterator, rather than
> Collector) makes things faster, it's still both work to track, propagate, and
> also becomes a side-channel that needs to remain in sync with the actual
> implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user. 

> One could argue that logic such as: someCollection.stream().map(?).count() is a
> performance bug/inefficiency in an of itself as it would be faster to do
> someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic. I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Saturday, 20 January 2024 17:40
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Thursday, January 18, 2024 5:14:38 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>> both gatherers keep it sorted.

>> That is unfortunately not the case. That would presume that you can implement
>> the composition such that it can preserve all the common flags. Some flags
>> could be "dominant" and some "recessive" to use genetics nomenclature.

> Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not
> the characteristics of the Gatherer which can have the corresponding "dominant"
> flag, GREEDY, in this case.
> And the same for sequential, the flag should be PARALELIZABLE and not
> SEQUENTIAL.

> The idea is that the Gatherer characteristics can have the same bit set at the
> same position as the stream op flags (as defined by StreamOpFlag).
> So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED
> is in position 3.
> For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit
> (using XOR) when we want to extract the stream op flags from the
> characteristics

> All the factory methods call the generic of() with a combination of
> PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY,
> KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be
> raised).

> In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for
> our two new states PARALELIZABLE and STATELESS, so no problem here (technically
> we can also reuse positions of the Spliterator characteristic given that those
> flags are masked before being sent to the GathererOp super constructor).

> The way to transform a Gatherer characteristics op to a stream flags op is to
> flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags
> but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask
> to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

> public static int toOpFlags ( int characteristics ) {
> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
> STREAM_OP_MASK ;
> }

> see below for a full script.

>>> I suppose that if those flags already exist, it's because they have a purpose
>>> and i do not understand how it can make the other operations slower.

>> Extra invocations, extra storage, and extra composition overhead is not free.
>> Since Stream is one-shot you need to include the construction cost with the
>> execution cost. For something like an empty Stream construction cost scan be
>> 90+% of the total costs.

> If you create a Gatherer, the characteristics is a constant (so the validity
> check is removed, it's just a mask and a test) so the result of calling
> toOpFlags() is a constant too.

> If the factory method is not inlined, the cost is 3 bitwise operations which is
> I believe faster than the "instanceof Greedy" used in the current code.

>> Cheers,
>> ?

> regards,
> R?mi

> ---
> public class GathererFlag {
> // cut and paste from StreamOpFlag
> /**
> * The bit pattern for setting/injecting a flag.
> */
> private static final int SET_BITS = 0b01 ;

> /**
> * The bit pattern for clearing a flag.
> */
> private static final int CLEAR_BITS = 0b10 ;

> /**
> * The bit pattern for preserving a flag.
> */
> private static final int PRESERVE_BITS = 0b11 ;

> private static int position ( int opFlagSet ) {
> return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ;
> }

> private static final int DISTINCT_POSITION = position ( StreamOpFlag .
> IS_DISTINCT );
> private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED
> );
> private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED );

> private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag .
> IS_SHORT_CIRCUIT );
> private static final int STATELESS_POSITION = 14 ;
> private static final int PARELLIZABLE_POSITION = 15 ;

> public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1
> );
> public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 );
> public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 );

> public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 );
> public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 );
> public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 );

> private static final int SHORT_CIRCUIT_MASK = SET_BITS << (
> SHORT_CIRCUIT_POSITION << 1 );

> // no GREEDY here
> private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS |
> KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ;

> private static final int STREAM_OP_MASK =
> (( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) |
> GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ;

> public static String toString ( int characteristics ) {
> return Stream . of ( characteristics )
> .< String >mapMulti(( f , consumer ) -> {
> if (( f & PARELLIZABLE ) == PARELLIZABLE ) {
> consumer .accept( "PARELLIZABLE" );
> }
> if (( f & STATELESS ) == STATELESS ) {
> consumer .accept( "STATELESS" );
> }
> if (( f & GREEDY ) == GREEDY ) {
> consumer .accept( "GREEDY" );
> }
> if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) {
> consumer .accept( "KEEP_DISTINCT" );
> }
> if (( f & KEEP_SORTED ) == KEEP_SORTED ) {
> consumer .accept( "KEEP_SORTED" );
> }
> if (( f & KEEP_SIZED ) == KEEP_SIZED ) {
> consumer .accept( "KEEP_SIZED" );
> }
> })
> .collect( Collectors . joining ( ", " ));
> }

> public static int toOpFlags ( int characteristics ) {
> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
> STREAM_OP_MASK ;
> }

> public static String toOpFlagsString ( int opFlags ) {
> return Arrays . stream ( StreamOpFlag . values ())
> .map( op -> {
> if ( op .isPreserved( opFlags )) {
> return "preserved " + op ;
> }
> if ( op .isCleared( opFlags )) {
> return "cleared " + op ;
> }
> if ( op .isKnown( opFlags )) {
> return "set " + op ;
> }
> return "?? " + op ;
> })
> .collect( Collectors . joining ( ", " ));
> }

> void main () {
> var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT |
> KEEP_SORTED | KEEP_SIZED ;
> System . out .println( toOpFlagsString ( toOpFlags ( characteristics )));

> var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ;
> System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 )));
> }
> }

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Thursday, 18 January 2024 16:17
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Thursday, January 18, 2024 3:36:07 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>>> others will want to be able to have INJECT-flags, and then people might have
>>> different opinions w.r.t. the default should be to clear all flags etc.

>>> And that's even before one looks at the composition-part of it, what are the
>>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>>> set of flags always approaches 0)

>>> I spent quite a bit of time on this and in the end tracking all this info, and
>>> making sure that the flags of implementations correspond to the actual
>>> behavior, just ended up costing performance for most streams and introduced an
>>> extra dimension to creation and maintenance which I had a hard time justifying.

>> It can be a slippery slope if we were designing from the ground up but the
>> stream implementation already exists and SORTED, DISTINCT and SIZED are the
>> flags that are already tracked by the current implementation.

>> Currently only SHORT_CIRCUIT is set (if not greedy),
>> see [
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
>> |
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
>> ]

>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>> both gatherers keep it sorted.

>>> Making specific, rare, combinations of operations faster at the expense of
>>> making 99% of all others slower is a hard pill for most to swallow.

>> I suppose that if those flags already exist, it's because they have a purpose
>> and i do not understand how it can make the other operations slower.

>>> Cheers,
>>> ?

>> regards,
>> R?mi

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Thursday, 18 January 2024 10:28
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>>> <core-libs-dev at openjdk.java.net>
>>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>> Hi R?mi,

>>>> You can find some of my benches here: [
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>>> |
>>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>>> ]

>>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>>> didn't end up worth it when looking at the bench results over a wide array of
>>>> stream sizes and number of operations.

>>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>>> KEEP_DISTINCT and KEEP_SIZED,
>>> all of them say that if the stream was sorted/distinct/sized then the stream
>>> returned by a call to gather() is still sorted (with the same comparator),
>>> distinct or sized.

>>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>>> windowFixed is KEEP_DISTINCT.

>>> [CC Paul, so he can correct me if i'm saying something stupid]

>>> Now for the benchmarks, it depends what you want to measure, benchmarking
>>> streams is tricky. This is what i know about benchmarking streams.
>>> First, the JIT has two ways to profile types at runtime,
>>> Either a method takes a function as parameter
>>> void map(Function function) {
>>> function.apply(...)
>>> }
>>> and when map is called with a subtype of Function, the JIT will propagate the
>>> exact type when map is inlined,
>>> Or a method use a field
>>> class Op {
>>> Function function;

>>> void map() {
>>> function.apply(...)
>>> }
>>> }
>>> in that case, the VM records the profile of function.apply() and if there are
>>> more than two different profiles, the VM declare profile poluttion and do not
>>> try to optimize.

>>> The Stream implementation tries very hard to use only parameters instead of
>>> fields, that's why it does not use classical Iterator that are pull iterator (a
>>> filter iterator requires a field) but a Spliterator which is a push iterator,
>>> the element is sent as parameter of the consumer.That's also why collect does
>>> not use the builder pattern (that accumulate values in fields) but a Collector
>>> that publish the functions to be called as parameter.

>>> Obvisously, this is more complex than that, a Collector stores the functions in
>>> fields so it should not work well but the implementation uses a record that
>>> plays well with escape analysis. Escape analysis see the fields of an instance
>>> as parameters so the functions of a Collector are correctly propagated (if the
>>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>>> are routinely fully inlined with the intermediate operation of a stream.

>>> In your tests, i've not seen comparaisons between an existing method like map()
>>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>>> where the characteristics KEEP_* have an impact and their equivalent using a
>>> Gatherer.

>>>> Cheers,
>>>> ?

>>> regards,
>>> R?mi

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>>> <forax at univ-mlv.fr>
>>>> Sent: Wednesday, 17 January 2024 16:48
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Subject: Gatherer: spliterator characteristics are not propagated
>>>> While doing some benchmarking of the Gatherer API, i've found that the
>>>> characteristics of the spliterator was not propagated by the method
>>>> Stream.gather() making the stream slower than it should.

>>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>>> that this intermediate operation keep the size, which is important if the
>>>> terminal operation is toList() because if the size is known, toList() will
>>>> presize the List and avoid the creation of an intermediary ArrayList.

>>>> See [
>>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>>> |
>>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>>> ]

>>>> I think that adding a way to propagate the spliterator characteristics through a
>>>> Gatherer would greatly improve the performance of commons streams (at least all
>>>> the ones that end with a call to toList).

>>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>>> something and if improving the performance is something worth changing the API.

>>>> regards,
>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240122/668a6036/attachment-0001.htm>

From sviswanathan at openjdk.org  Mon Jan 22 19:57:27 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 22 Jan 2024 19:57:27 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v8]
In-Reply-To: <nwMMHGrRLsstg6Fbi-ZeFKZFrpu_kn-uo_nMalUd52M=.15c93d29-0506-4671-b154-9879cc56a3c4@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <nwMMHGrRLsstg6Fbi-ZeFKZFrpu_kn-uo_nMalUd52M=.15c93d29-0506-4671-b154-9879cc56a3c4@github.com>
Message-ID: <LZGHGUV05s_xPuLFh1pHFrKGB0oStDEdfSE1waOki68=.d9725b74-3c71-4f7b-abb5-3e19544f852e@github.com>

On Sat, 20 Jan 2024 09:55:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Nice work! The patch looks good to me now.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1837250879

From bpb at openjdk.org  Mon Jan 22 20:05:30 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Jan 2024 20:05:30 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v4]
In-Reply-To: <mvrLHlhNJCbdReq6G80wkQlFGecoF1KzULtb87J9Kuw=.47be72d7-a8a5-4afd-b620-1fc0dd0b56d6@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <mvrLHlhNJCbdReq6G80wkQlFGecoF1KzULtb87J9Kuw=.47be72d7-a8a5-4afd-b620-1fc0dd0b56d6@github.com>
Message-ID: <W7zkeP2rNRixXWm7BcZhPjnOx-LjJ7iUD8xI6WH-GYU=.ca083606-0d4a-49e0-b68e-1c267bf3f497@github.com>

On Mon, 22 Jan 2024 18:52:43 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestDivWord.java
>   
>   Added method to check results of divWord

test/jdk/java/math/BigInteger/TestDivWord.java line 5:

> 3: import java.util.Random;
> 4: 
> 5: public class TestDivWord {

Where is this used in actually jtreg testing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17291#discussion_r1462355967

From viktor.klang at oracle.com  Mon Jan 22 21:06:27 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 22 Jan 2024 21:06:27 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D202E81DEED1C2FF07FCFF722@MW4PR10MB5774.namprd10.prod.outlook.com>
 <955395864.105376522.1705570107682.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>


The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.
But I presume this also requires to have a `int characteristics()`-method on the Gatherer interfacewhich means that users who are not using the factory methods will have full possibility of not only returning the flags, but returning any int.


The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.
I can see where you're coming from here, but to me, adding API surface needs to pull its weight.
In this case I wasn't convinced that it did, hence we're having this conversation. ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.





Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.


public static int toOpFlags(int characteristics) {
  return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---

public class GathererFlag {
  // cut and paste from StreamOpFlag
  /**
   * The bit pattern for setting/injecting a flag.
   */
private static final int SET_BITS = 0b01;

  /**
   * The bit pattern for clearing a flag.
   */
private static final int CLEAR_BITS = 0b10;

  /**
   * The bit pattern for preserving a flag.
   */
private static final int PRESERVE_BITS = 0b11;


  private static int position(int opFlagSet) {
    return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
  }

  private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
  private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
  private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

  private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
  private static final int STATELESS_POSITION = 14;
  private static final int PARELLIZABLE_POSITION = 15;

  public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
  public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
  public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

  public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
  public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
  public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

  private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

  // no GREEDY here
private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

  private static final int STREAM_OP_MASK =
      ((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
      GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

  public static String toString(int characteristics) {
    return Stream.of(characteristics)
        .<String>mapMulti((f, consumer) -> {
          if ((f & PARELLIZABLE) == PARELLIZABLE) {
            consumer.accept("PARELLIZABLE");
          }
          if ((f & STATELESS) == STATELESS) {
            consumer.accept("STATELESS");
          }
          if ((f & GREEDY) == GREEDY) {
            consumer.accept("GREEDY");
          }
          if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
            consumer.accept("KEEP_DISTINCT");
          }
          if ((f & KEEP_SORTED) == KEEP_SORTED) {
            consumer.accept("KEEP_SORTED");
          }
          if ((f & KEEP_SIZED) == KEEP_SIZED) {
            consumer.accept("KEEP_SIZED");
          }
        })
        .collect(Collectors.joining(", "));
  }

  public static int toOpFlags(int characteristics) {
    return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240122/3b16ebef/attachment-0001.htm>

From bpb at openjdk.org  Mon Jan 22 21:06:39 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Jan 2024 21:06:39 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: <LGOJSqdmT5P9rDLsZBl27GuTyBvWdXPCI_7M1nhja2o=.bc9b7870-740f-42dd-ab86-e82e831ee3ba@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.

Will more work be done on this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1904812784

From duke at openjdk.org  Mon Jan 22 21:24:29 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 21:24:29 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v4]
In-Reply-To: <W7zkeP2rNRixXWm7BcZhPjnOx-LjJ7iUD8xI6WH-GYU=.ca083606-0d4a-49e0-b68e-1c267bf3f497@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <mvrLHlhNJCbdReq6G80wkQlFGecoF1KzULtb87J9Kuw=.47be72d7-a8a5-4afd-b620-1fc0dd0b56d6@github.com>
 <W7zkeP2rNRixXWm7BcZhPjnOx-LjJ7iUD8xI6WH-GYU=.ca083606-0d4a-49e0-b68e-1c267bf3f497@github.com>
Message-ID: <Y7Kkw-tA-kcxZ4JgtuVTGjGMwKZSJNbHExcN2hKHabY=.6a0e3f89-45a6-4e19-b929-c5f3adbc110e@github.com>

On Mon, 22 Jan 2024 20:02:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TestDivWord.java
>>   
>>   Added method to check results of divWord
>
> test/jdk/java/math/BigInteger/TestDivWord.java line 5:
> 
>> 3: import java.util.Random;
>> 4: 
>> 5: public class TestDivWord {
> 
> Where is this used in actually jtreg testing?

@bplb It is not used in jtreg testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17291#discussion_r1462437309

From bpb at openjdk.org  Mon Jan 22 21:29:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Jan 2024 21:29:27 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v4]
In-Reply-To: <Y7Kkw-tA-kcxZ4JgtuVTGjGMwKZSJNbHExcN2hKHabY=.6a0e3f89-45a6-4e19-b929-c5f3adbc110e@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <mvrLHlhNJCbdReq6G80wkQlFGecoF1KzULtb87J9Kuw=.47be72d7-a8a5-4afd-b620-1fc0dd0b56d6@github.com>
 <W7zkeP2rNRixXWm7BcZhPjnOx-LjJ7iUD8xI6WH-GYU=.ca083606-0d4a-49e0-b68e-1c267bf3f497@github.com>
 <Y7Kkw-tA-kcxZ4JgtuVTGjGMwKZSJNbHExcN2hKHabY=.6a0e3f89-45a6-4e19-b929-c5f3adbc110e@github.com>
Message-ID: <HDwlho_T-GeiRrVLFbwy5hfp9qWwVTB0NPITisNvYXk=.ce994bb5-ed9e-4d2f-90e2-f28a6f342c68@github.com>

On Mon, 22 Jan 2024 21:21:53 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> test/jdk/java/math/BigInteger/TestDivWord.java line 5:
>> 
>>> 3: import java.util.Random;
>>> 4: 
>>> 5: public class TestDivWord {
>> 
>> Where is this used in actually jtreg testing?
>
> @bplb It is not used in jtreg testing.

So it is only for verification purposes in the context of this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17291#discussion_r1462441622

From duke at openjdk.org  Mon Jan 22 21:32:28 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 22 Jan 2024 21:32:28 GMT
Subject: RFR: JDK-8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int) [v4]
In-Reply-To: <HDwlho_T-GeiRrVLFbwy5hfp9qWwVTB0NPITisNvYXk=.ce994bb5-ed9e-4d2f-90e2-f28a6f342c68@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
 <mvrLHlhNJCbdReq6G80wkQlFGecoF1KzULtb87J9Kuw=.47be72d7-a8a5-4afd-b620-1fc0dd0b56d6@github.com>
 <W7zkeP2rNRixXWm7BcZhPjnOx-LjJ7iUD8xI6WH-GYU=.ca083606-0d4a-49e0-b68e-1c267bf3f497@github.com>
 <Y7Kkw-tA-kcxZ4JgtuVTGjGMwKZSJNbHExcN2hKHabY=.6a0e3f89-45a6-4e19-b929-c5f3adbc110e@github.com>
 <HDwlho_T-GeiRrVLFbwy5hfp9qWwVTB0NPITisNvYXk=.ce994bb5-ed9e-4d2f-90e2-f28a6f342c68@github.com>
Message-ID: <otNWBiXXseOby9uUPoRVtVFbTvKkB-rupgbUzQlBvN0=.642963cf-197c-4263-af34-5d84c5cace70@github.com>

On Mon, 22 Jan 2024 21:26:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> @bplb It is not used in jtreg testing.
>
> So it is only for verification purposes in the context of this PR?

@bplb Yes, it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17291#discussion_r1462444386

From duke at openjdk.org  Mon Jan 22 22:13:50 2024
From: duke at openjdk.org (Joshua Cao)
Date: Mon, 22 Jan 2024 22:13:50 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v4]
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <wpea4DjJRgCr3vaqSScAokbaN4h9O3e9FE-BHhgsfzg=.73c89d8c-b6e3-40ea-91b9-e279d7e0f930@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%.
> 
> ### JMH results for testPutAll (size = 10000)
> 
> before patch:
> 
> 
> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>   4315291.542 ?(99.9%) 336034.190 ns/op [Average]
>   (min, avg, max) = (3974688.194, 4315291.542, 4871772.209), stdev = 314326.589
>   CI (99.9%): [3979257.352, 4651325.731] (assumes normal distribution)
> 
> 
> after patch:
> 
> 
> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>   3006955.723 ?(99.9%) 271757.969 ns/op [Average]
>   (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev = 254202.573
>   CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
> 
> 
> Average time is decreased about 30%.

Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:

  pass initial size to putAll benchmark map construction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17116/files
  - new: https://git.openjdk.org/jdk/pull/17116/files/3efa593d..2a965fa9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17116&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17116&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Mon Jan 22 22:13:52 2024
From: duke at openjdk.org (Joshua Cao)
Date: Mon, 22 Jan 2024 22:13:52 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v3]
In-Reply-To: <KqR1DoTjCohxJZMyc6zOBod4XxbGBjmLmKbRH_cdpYo=.a636b2b6-5747-45f9-9b55-4896ea666e39@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
 <KqR1DoTjCohxJZMyc6zOBod4XxbGBjmLmKbRH_cdpYo=.a636b2b6-5747-45f9-9b55-4896ea666e39@github.com>
Message-ID: <gRs_lFot4cIGgfVeeOdqNDp6HP6VemUHNd7JLfuWhSc=.19223187-9ea6-4286-97a3-827194843edd@github.com>

On Mon, 22 Jan 2024 17:45:45 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   putAll presize based on sum on both map sizes
>
> test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:
> 
>> 120:     @Benchmark
>> 121:     public ConcurrentHashMap<Integer, Integer> testConcurrentHashMapPutAll() {
>> 122:         ConcurrentHashMap<Integer, Integer> map = new ConcurrentHashMap<>();
> 
> I think this benchmark could be made more accurate by creating the new, temporary map with the right initial size (i.e. `ConcurrentHashMap<>(nkeys)`) to avoid calls to `tryPresize()` in this setup step.

I updated. The numbers are surprisingly the same. I guess the benchmark compute time is dominated by putAll().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1462481286

From jlu at openjdk.org  Mon Jan 22 22:54:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 Jan 2024 22:54:26 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v4]
In-Reply-To: <ROYcHd4rqA0XB__-nHTZJ2YXNwxybW1fcREDnT7L4C4=.4d810fff-6c92-4045-8f0d-a6ba73db040c@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
 <ROYcHd4rqA0XB__-nHTZJ2YXNwxybW1fcREDnT7L4C4=.4d810fff-6c92-4045-8f0d-a6ba73db040c@github.com>
Message-ID: <8mM5JCWtyyOsfOo23GuHUPi9a0rI8RQRCA2usw92vkY=.62fc94ad-d52a-4f9a-bb0d-abe35ae82748@github.com>

On Fri, 12 Jan 2024 21:30:05 GMT, Roger Riggs <rriggs 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 eight additional commits since the last revision:
>> 
>>  - replace 'None' with 'null' for applicable classes
>>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>>  - swap placement of decimal pattern and compact patterns. Expand on tests
>>  - add unit tests
>>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>>  - account for null locale for SDF through deserialization
>>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>>  - init
>
> src/java.base/share/classes/java/text/MessageFormat.java line 1195:
> 
>> 1193:             """
>> 1194:             MessageFormat [locale: "%s", pattern: "%s"]
>> 1195:             """.formatted(locale == null ? "null" : locale.getDisplayName(), toPattern());
> 
> It would be more accurate if when locale ==null that null was not quoted in the string.
> Seeing "null" would imply that the displayName of the locale was "null", when it was `null`.

Hi Roger, addressed in https://github.com/openjdk/jdk/pull/17355/commits/70e0a175037ccd0215d76fb2fbfa8c91de291d41; would like to confirm the update is okay with you before integration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1462516181

From lancea at openjdk.org  Mon Jan 22 22:57:33 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 22 Jan 2024 22:57:33 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v12]
In-Reply-To: <L_P2PB_bBvzFyQVyRnjayW-qHrMax6U_pfj3-Xl90mI=.7e7d68b8-0a12-4049-ada8-34d4a9a99701@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <EZf20ty1JNF9cVjedm1YCqtcJn3wVgWyivESrJQs5nU=.6bca47cc-75e9-4497-8bda-406abb3c395e@github.com>
 <33U0s06xG2FNIDYsaZ0oPOnF1uoZUw4cwZgpY1AYrhI=.4d6e8dc7-8cba-41f0-bd8b-252d64e810fb@github.com>
 <guU5N9ppbMKZvGppayMCoUAAlxGiSt7cTs71d9I40HE=.43440217-73fc-431f-9da9-8268d15ad805@github.com>
 <ga90hOxKqdOMq97zdDfeobco2FXuQOjF-Pdfn4jhgVU=.28131301-7ca6-48b7-8e7f-444fc3994d87@github.com>
 <L_P2PB_bBvzFyQVyRnjayW-qHrMax6U_pfj3-Xl90mI=.7e7d68b8-0a12-4049-ada8-34d4a9a99701@github.com>
Message-ID: <f4rgzINUZ-oCnmbgzNAdvnatXzeVESab0zlhjVCHzmQ=.53aba092-a41b-40cf-8736-5a06760aff98@github.com>

On Mon, 22 Jan 2024 14:34:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> @LanceAndersen Do you have a cent or two to spare?

Let me try and dig out from a couple of things and circle back to this again

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1462519461

From dholmes at openjdk.org  Tue Jan 23 01:35:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Jan 2024 01:35:27 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
Message-ID: <wfKhDlxr72y_dElp3S5etGEXx69UMNlo4LDxwvpihqY=.5705f0df-b42a-47d3-b1a6-5417b2d7e382@github.com>

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
> 
> I provisionally call this flag `external-dep`, but I am open for other suggestions.
> 
> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
> 
> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
> 
> Additional testing:
>  - [x] `make test TEST=applications/` fails
>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests

Seems quite reasonable.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17421#pullrequestreview-1837713758

From duke at openjdk.org  Tue Jan 23 01:45:27 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 01:45:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <LrIsvPuptlg6kpZIiEg2al4DO1sMxtQFcY-iOXx_5mg=.53e24cae-bd26-4c11-babb-a582d0971f13@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <LrIsvPuptlg6kpZIiEg2al4DO1sMxtQFcY-iOXx_5mg=.53e24cae-bd26-4c11-babb-a582d0971f13@github.com>
Message-ID: <oT8uw1KKw8Td3c4XMWO_h0hzlFIpkv_pdiDQXtJXfXI=.a440943e-c4b4-4c9f-be97-4ce35b977b59@github.com>

On Mon, 22 Jan 2024 15:03:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> `1k` increments for a total of `512k` times seems overkill. Are you sure that's needed to make the test pass? How about `1MB` increments for a total of `512` times?

When the docker serivice work normally on the test machine, this test will always fail. This test want to verify the API `jdk.internal.platform.Metrics.systemMetrics().getMemoryFailCount()` work normally or not. The API return memory allocate fail times in jvm. But, before this PR, everytime it allocate `1M` memory, the API has no chance the catch the memory allocate fail, the jvm was killed by OOM. Change `8M` increments to `1K` mean to avoid OOM killed for the jvm in docker container.

jvm was killed by OOM in docker container:

![image](https://github.com/openjdk/jdk/assets/24123821/c00697cc-ceef-410e-a8b9-7c401fa76134)


`1M` Increnents also can avoid OOM killed.

![image](https://github.com/openjdk/jdk/assets/24123821/bab0a753-d15c-4759-a557-b8feafaa97cb)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1905139487

From duke at openjdk.org  Tue Jan 23 01:58:40 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 01:58:40 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v2]
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <yhwpfIMqwuQ158zvVxkWSew3trCHzoulCcD5c57JGb4=.7b055d31-0863-4c61-9e47-a746e51eacb7@github.com>

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

sendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
  
  Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17514/files
  - new: https://git.openjdk.org/jdk/pull/17514/files/be81665d..969b608d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17514&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17514&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17514/head:pull/17514

PR: https://git.openjdk.org/jdk/pull/17514

From qamai at openjdk.org  Tue Jan 23 08:18:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 08:18:41 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
Message-ID: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>

Hi,

This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.

Please kindly give your opinion as well as your reviews, thanks very much.

-------------

Commit messages:
 - bug number
 - add isConstantExpression

Changes: https://git.openjdk.org/jdk/pull/17527/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324433
  Stats: 162 lines in 6 files changed: 158 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From shade at openjdk.org  Tue Jan 23 08:18:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 08:18:41 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>

On Tue, 23 Jan 2024 08:10:54 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Nice. I had a similar thing stashed in my todo queue. Note that there is already `isCompileConstant` that does similar thing: https://github.com/openjdk/jdk/blob/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/hotspot/share/opto/library_call.cpp#L8189-L8193 -- maybe we should just expose that more widely. I would suggest we just do the private `java.lang.{Integer,...}.isCompileConstant` methods and bind them to that intrinsic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1905504206

From epeter at openjdk.org  Tue Jan 23 08:22:33 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 23 Jan 2024 08:22:33 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v8]
In-Reply-To: <nwMMHGrRLsstg6Fbi-ZeFKZFrpu_kn-uo_nMalUd52M=.15c93d29-0506-4671-b154-9879cc56a3c4@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <nwMMHGrRLsstg6Fbi-ZeFKZFrpu_kn-uo_nMalUd52M=.15c93d29-0506-4671-b154-9879cc56a3c4@github.com>
Message-ID: <DF0UnCzvElf2EM2yCIZfSY0vVWchj_CFsnzZ9sJzeaU=.d6f9039e-3207-462e-b307-5efcb897a61e@github.com>

On Sat, 20 Jan 2024 09:55:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Looks good, except for one detail ;)

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5301:

> 5299:     vmovmskps(rtmp, mask, vec_enc);
> 5300:   }
> 5301:   shlq(rtmp, 5); // for 32 byte permute row of 8 x 32 bits.

Suggestion:

  shlq(rtmp, 5); // for 32 byte permute row of 8 x 32 bits / 4 x 64 bits.

Since you now merged the code of the two paths

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1838095271
PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1462873120

From qamai at openjdk.org  Tue Jan 23 09:20:46 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 09:20:46 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v2]
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <pwkv5vX00SyxlsZ6HZi8Ge3AakrHIbZ59JaIKUiaQgU=.d0fe57ac-ba4b-4427-9e2a-a379b1a0492a@github.com>

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  use inline_isCompileConstant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17527/files
  - new: https://git.openjdk.org/jdk/pull/17527/files/4d0fc3dd..9dd95393

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=00-01

  Stats: 13 lines in 3 files changed: 0 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From qamai at openjdk.org  Tue Jan 23 09:30:26 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 09:30:26 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
In-Reply-To: <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
Message-ID: <g39pZ5JiiIaR0DL24dOGIAUmsgEWXe8hLch5NgWTnOY=.d1b6bcba-b37c-4fe7-be9e-281ba628e2b7@github.com>

On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Nice. I had a similar thing stashed in my todo queue. Note that there is already `isCompileConstant` that does similar thing: https://github.com/openjdk/jdk/blob/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/hotspot/share/opto/library_call.cpp#L8189-L8193 -- maybe we should just expose that more widely. I would suggest we just do the private `java.lang.{Integer,...}.isCompileConstant` methods and bind them to that intrinsic.

@shipilev Thanks a lot for your suggestions. Yes I can just use `inline_isCompileConstant` instead.

Regarding the place of the method, I'm not really sure as putting in `java.lang.Long` seems out-of-place for an internal mechanism that is obviously not only used in `java.lang`, which will force a new entry in `JavaLangAccess`. Finally, I think accepting a `long` would be enough (maybe `double`, too?) since `int`, `boolean` etc can be converted losslessly to `long`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1905641141

From qamai at openjdk.org  Tue Jan 23 09:34:27 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 09:34:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
In-Reply-To: <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
Message-ID: <Ibjj4EBvnBZStvTfCadpCwnZ5cnPN1Ha20EwLVdBFAA=.2c6989ef-a92e-4e23-9e4e-c23bff873628@github.com>

On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I would suggest we just do the private `java.lang.{Integer,...}.isCompileConstant` methods and bind them to that intrinsic.

Maybe I am ignorant but doesn't the definition of an intrinsics contain the signature of the method as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1905648723

From shade at openjdk.org  Tue Jan 23 09:38:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 09:38:24 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
In-Reply-To: <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
Message-ID: <wqemyjdPr820hQo5CoZaEsMFLgTVI_-g2efz3_vMXAI=.13ce14d6-417a-4312-ac3b-0891eb8c3c07@github.com>

On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Nice. I had a similar thing stashed in my todo queue. Note that there is already `isCompileConstant` that does similar thing: https://github.com/openjdk/jdk/blob/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/hotspot/share/opto/library_call.cpp#L8189-L8193 -- maybe we should just expose that more widely. I would suggest we just do the private `java.lang.{Integer,...}.isCompileConstant` methods and bind them to that intrinsic.

> @shipilev Thanks a lot for your suggestions. Yes I can just use `inline_isCompileConstant` instead.
> 
> Regarding the place of the method, I'm not really sure as putting in `java.lang.Long` seems out-of-place for an internal mechanism that is obviously not only used in `java.lang`, which will force a new entry in `JavaLangAccess`. 

Ah yes, if you need to use it across module boundaries, putting the private/protected method would require `JavaLangAccess`, which is burdensome. I am just icky about introducing a whole new internal class for this. Is there anything in current `jdk.internal.vm.*` that fits it? Maybe `misc.Unsafe` or `misc.VM`?

> Finally, I think accepting a `long` would be enough (maybe `double`, too?) since `int`, `boolean` etc can be converted losslessly to `long`.

Right, that would work for primitives, since we could probably rely on conversion for constants to be folded. But I also see the value for asking `isCompileConstant(Object)`, which is not easily convertible. So I would just do the overloads for all primitives and `Object`. The C2 intrinsic would not care about the `arg(0)` type, it would reply `isCon` on those constants just the same.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1905655407

From shade at openjdk.org  Tue Jan 23 09:45:27 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 09:45:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
In-Reply-To: <Ibjj4EBvnBZStvTfCadpCwnZ5cnPN1Ha20EwLVdBFAA=.2c6989ef-a92e-4e23-9e4e-c23bff873628@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <dGmOF9ddvxvi1mfHCqGtTN5aFFLh2cu4IKyKJCXu4qY=.5708e124-e3a8-4f59-9c84-0bc6c0cc6bca@github.com>
 <Ibjj4EBvnBZStvTfCadpCwnZ5cnPN1Ha20EwLVdBFAA=.2c6989ef-a92e-4e23-9e4e-c23bff873628@github.com>
Message-ID: <9xpFtQX-wVtXnENNNiQZZFJqa7cy-n7_yS6uU3UjsQ8=.55c6a9b6-0e89-45f7-bfb9-11b13f9ef605@github.com>

On Tue, 23 Jan 2024 09:31:51 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Maybe I am ignorant but doesn't the definition of an intrinsics contain the signature of the method as well?

The definitions in `vmIntrinsics`, sure, they require full signature for `@IntrinsicCandidate` methods. It would yield some unfortunate duplication. But after that, we can map on the same `inline_isCompileConstant` intrinsic that just asks `arg(0)->is_Con()`, and it would not care about the type of the constant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1905667006

From sgehwolf at openjdk.org  Tue Jan 23 09:45:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 09:45:30 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v2]
In-Reply-To: <yhwpfIMqwuQ158zvVxkWSew3trCHzoulCcD5c57JGb4=.7b055d31-0863-4c61-9e47-a746e51eacb7@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <yhwpfIMqwuQ158zvVxkWSew3trCHzoulCcD5c57JGb4=.7b055d31-0863-4c61-9e47-a746e51eacb7@github.com>
Message-ID: <upACV4uWbUEt1pyRSTE3ieAy7fD4YEmyxl82WqT9WqI=.e551f527-fa63-408d-bc74-8fa877306d56@github.com>

On Tue, 23 Jan 2024 01:58:40 GMT, sendaoYan <duke at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Looks fine now.

test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java line 75:

> 73:             long count = Metrics.systemMetrics().getMemoryFailCount();
> 74: 
> 75:             // Allocate 512M of data

Suggestion: Amend the comment to `Allocate 512M of data in 1M chunks per iteration`

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17514#pullrequestreview-1838306348
PR Review Comment: https://git.openjdk.org/jdk/pull/17514#discussion_r1462991886

From duke at openjdk.org  Tue Jan 23 09:59:38 2024
From: duke at openjdk.org (duke)
Date: Tue, 23 Jan 2024 09:59:38 GMT
Subject: Withdrawn: 8318966: Some methods make promises about Java array
 element alignment that are too strong
In-Reply-To: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
References: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
Message-ID: <k8nBVw32SLtA46rk7pLNnjarEb1iyCNus7CM_dGynQQ=.e22cfdd9-fa57-44f7-860e-1d208c54e950@github.com>

On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for an extended problem description.
> 
> This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment).
> 
> - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1].
> 
> - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used.
> 
> - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification:
> 
> 
>      * @throws UnsupportedOperationException
>      *         If the native platform does not guarantee stable alignment offset
>      *         values for the given unit size when managing the memory regions
>      *         of buffers of the same kind as this buffer (direct or
>      *         non-direct).  For example, if garbage collection would result
>      *         in the mo...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16681

From shade at openjdk.org  Tue Jan 23 10:15:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 10:15:28 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <wfKhDlxr72y_dElp3S5etGEXx69UMNlo4LDxwvpihqY=.5705f0df-b42a-47d3-b1a6-5417b2d7e382@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
 <wfKhDlxr72y_dElp3S5etGEXx69UMNlo4LDxwvpihqY=.5705f0df-b42a-47d3-b1a6-5417b2d7e382@github.com>
Message-ID: <S-U-DUzCfpMLHGPMTI87Ok6gNFc8-SV8I6v2gNRk0SY=.874feabb-5369-49f5-93ea-1f0b9f4400e2@github.com>

On Tue, 23 Jan 2024 01:32:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems quite reasonable.

Thanks!

I shall wait for more reviewers, in case someone has an issue with `external-dep` as the flag name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1905719123

From goetz at openjdk.org  Tue Jan 23 10:28:43 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 23 Jan 2024 10:28:43 GMT
Subject: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
Message-ID: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>

I backport this to fix this issue in 22. We see it failing there in our CI.

-------------

Commit messages:
 - Backport c2e77e2f17b624e750dea8fd51bbfde99596690e

Changes: https://git.openjdk.org/jdk22/pull/95/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=95&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319128
  Stats: 45 lines in 6 files changed: 36 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk22/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/95/head:pull/95

PR: https://git.openjdk.org/jdk22/pull/95

From qamai at openjdk.org  Tue Jan 23 11:18:43 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 11:18:43 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add more overloads

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17527/files
  - new: https://git.openjdk.org/jdk/pull/17527/files/9dd95393..31403d6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=01-02

  Stats: 346 lines in 6 files changed: 333 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From qamai at openjdk.org  Tue Jan 23 11:26:26 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 11:26:26 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
Message-ID: <3pUibPS3iTDkTve0coFDSCFt61RLryW5Hc7Jve6Cfk8=.9bb8d2f8-59fd-4958-8d04-b8b13f17b7b3@github.com>

On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more overloads

I get your idea. I have added overloads for all types. They will all invoke `inlint_isCompileConstant`. Given that there are now 7 methods I think a separate class is more justified.

Another issue is the duplication of `isConstantExpression(Object)`, but I think a separate issue to deduplicate it would be easier.

Thanks a lot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1905836929

From jlahoda at openjdk.org  Tue Jan 23 11:45:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Jan 2024 11:45:28 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <zWTW573x0Oeknlv1bUsm-fL3AkdrAc2GnavlMwc1LKA=.55ba1805-0f6b-4c5c-b4d6-a7b42a9c4ee3@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

I have nothing against it, but I don't think I know enough about details of jtreg configuration to provide approval. OTOH, I personally don't see a strong need for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1905864727

From jbhateja at openjdk.org  Tue Jan 23 11:56:58 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 23 Jan 2024 11:56:58 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v9]
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

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 10 additional commits since the last revision:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8322768
 - Modifying comments.
 - Review comments resolution
 - Modified code comment for clarity.
 - Space fixup
 - Using emulated variable blend E-Core optimized instruction.
 - Review suggestions incorporated.
 - Review comments resolutions.
 - Updating copyright year of modified files.
 - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17261/files
  - new: https://git.openjdk.org/jdk/pull/17261/files/cd912308..83e4065e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17261&range=07-08

  Stats: 41105 lines in 1072 files changed: 24738 ins; 11390 del; 4977 mod
  Patch: https://git.openjdk.org/jdk/pull/17261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17261/head:pull/17261

PR: https://git.openjdk.org/jdk/pull/17261

From jbhateja at openjdk.org  Tue Jan 23 11:56:58 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 23 Jan 2024 11:56:58 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v8]
In-Reply-To: <DF0UnCzvElf2EM2yCIZfSY0vVWchj_CFsnzZ9sJzeaU=.d6f9039e-3207-462e-b307-5efcb897a61e@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <nwMMHGrRLsstg6Fbi-ZeFKZFrpu_kn-uo_nMalUd52M=.15c93d29-0506-4671-b154-9879cc56a3c4@github.com>
 <DF0UnCzvElf2EM2yCIZfSY0vVWchj_CFsnzZ9sJzeaU=.d6f9039e-3207-462e-b307-5efcb897a61e@github.com>
Message-ID: <GkxhLjQ1Y4oZXXpRIQLd10Z2uUyL9ZEkmIxWZ0y_-xw=.ea86f0d2-d106-4295-9e88-7ab33b88ecd1@github.com>

On Tue, 23 Jan 2024 08:17:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5301:
> 
>> 5299:     vmovmskps(rtmp, mask, vec_enc);
>> 5300:   }
>> 5301:   shlq(rtmp, 5); // for 32 byte permute row of 8 x 32 bits.
> 
> Suggestion:
> 
>   shlq(rtmp, 5); // for 32 byte permute row of 8 x 32 bits / 4 x 64 bits.
> 
> Since you now merged the code of the two paths

As per the latest patch, we are doing a double word permute, hence semantically its ok and in accordance with instruction sequence :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17261#discussion_r1463160336

From duke at openjdk.org  Tue Jan 23 13:04:43 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 13:04:43 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

sendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
  
  Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17514/files
  - new: https://git.openjdk.org/jdk/pull/17514/files/969b608d..d1eb4fac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17514&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17514&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17514/head:pull/17514

PR: https://git.openjdk.org/jdk/pull/17514

From sgehwolf at openjdk.org  Tue Jan 23 13:15:27 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 13:15:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
Message-ID: <546Ycpctif9TFb7wOeHWUmaPsNSRL3N_skBeNZsjioU=.f969cf54-fdae-4aba-a6e3-4b073cab4faa@github.com>

On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan <duke at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Marked as reviewed by sgehwolf (Reviewer).

Please enable GHA for your fork for future PRs.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17514#pullrequestreview-1838761515
PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1906034584

From duke at openjdk.org  Tue Jan 23 13:18:27 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 13:18:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
Message-ID: <7rRKRaahK5RQ3AFiOVAbt3-zZxpCayg8JJF9tCfQfrM=.3bb7a366-e61f-4d4b-98de-4011fdc3a6e9@github.com>

On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan <duke at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

> GHA



> Please enable GHA for your fork for future PRs.

OK

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1906038625

From duke at openjdk.org  Tue Jan 23 13:22:34 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 13:22:34 GMT
Subject: Integrated: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <zHxECVVzZwYzZtqYZCyE0wE2kDTidt141LB0ZPFFuck=.aa13576d-30e2-437f-8b0e-05ecf6a89720@github.com>

On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

This pull request has now been integrated.

Changeset: 791b427f
Author:    sendaoYan <yansendao.ysd at alibaba-inc.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/791b427f4410057cdcdf8fd8ea0dcce71f7dc513
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

Reviewed-by: sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/17514

From sgehwolf at openjdk.org  Tue Jan 23 14:23:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 14:23:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v14]
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: <wVJMt_pqvXeMU8Zo3WGMyT-fGHOaUTnBcQIa-RGWwj0=.4dc2657d-a02a-4dd4-bad0-ea03743a15f8@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 with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Add some details for run-time link
   
   Also clean up the --verbose output.
 - Always add the runtime image stamp file
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Rename '--unlock-run-image' to '--ignore-modified-runtime'
 - Remove --unlock-run-image from jlink.properties
 - Fix IntegrationTest (no runtime image link)
 - 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.  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.
 - 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.
 - Add @enablePreview for JImageValidator that uses classfile API
 - ... and 45 more: https://git.openjdk.org/jdk/compare/c9cacfb2...9635ba52

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=13
  Stats: 3211 lines in 39 files changed: 3041 ins; 132 del; 38 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 rriggs at openjdk.org  Tue Jan 23 14:45:25 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 23 Jan 2024 14:45:25 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
Message-ID: <l0ZryWB7izCE8t-fOyinka6Tr7VBmIPG3ozMwRwawds=.0ea851f1-6bd9-452f-be8f-3c8b6f300372@github.com>

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
> 
> I provisionally call this flag `external-dep`, but I am open for other suggestions.
> 
> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
> 
> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
> 
> Additional testing:
>  - [x] `make test TEST=applications/` fails
>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests

Is there any place to document the new keyword or its usage; it does not seem very discoverable just existing in the TEST.ROOT and some tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1906198126

From liach at openjdk.org  Tue Jan 23 14:46:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Jan 2024 14:46:36 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong
In-Reply-To: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
References: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
Message-ID: <l7jVhuR5JNdh41bqEcYQSXvwtEW5WBJyfrTV06iR_cc=.c78ddfad-5920-4c20-aab8-a65fb13a1762@github.com>

On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for an extended problem description.
> 
> This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment).
> 
> - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1].
> 
> - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used.
> 
> - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification:
> 
> 
>      * @throws UnsupportedOperationException
>      *         If the native platform does not guarantee stable alignment offset
>      *         values for the given unit size when managing the memory regions
>      *         of buffers of the same kind as this buffer (direct or
>      *         non-direct).  For example, if garbage collection would result
>      *         in the mo...

Also curious, is there any documentation (like JVMS) that allows JVMs to make no offset into byte arrays aligned for larger access? Would be helpful if we can have a reference here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1906200196

From liach at openjdk.org  Tue Jan 23 14:46:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Jan 2024 14:46:39 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong
In-Reply-To: <Y909Cm6M5nnx9oXb4Utjr5Kh-tbyFVEOuu2FuaBtpKw=.01277bfa-f509-40ac-8970-c81c00bf636d@github.com>
References: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
 <sPZzoVJ1mJYKNCf5EW69FVw22yZw4ZLzmRa79e4rg_E=.69ab3b67-767c-4485-8a0d-1f0fa9c02546@github.com>
 <Y909Cm6M5nnx9oXb4Utjr5Kh-tbyFVEOuu2FuaBtpKw=.01277bfa-f509-40ac-8970-c81c00bf636d@github.com>
Message-ID: <eF4H-n79i2jg3A1RtihDJLhrDGrDFVPIXSEKKD8KLIM=.b1aa9abb-5ff5-40d3-8b2a-6b053ddbef51@github.com>

On Thu, 16 Nov 2023 18:10:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4518:
>> 
>>> 4516:      * Only plain {@linkplain VarHandle.AccessMode#GET get} and {@linkplain VarHandle.AccessMode#SET set}
>>> 4517:      * access modes are supported by the returned var handle. For all other access modes, an
>>> 4518:      * {@link UnsupportedOperationException} will be thrown.
>> 
>> I recommend adding an api note explaining that native memory segments, direct byte buffers, or heap memory segments backed by long[] should be used if support for other access modes are required.
>
> Good idea. Thanks

Should we make these unaligned access modes throw ISE like before, when the given index is unaligned?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16681#discussion_r1463367572

From sgehwolf at openjdk.org  Tue Jan 23 14:48:34 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 14:48:34 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <oOdi9t6sNDmcOr7z5pgoIqeQIYJFZ2CnnC8Ix0rue-g=.ea771691-0683-4bbb-9a6c-7a029340d5d6@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>
 <aEJ_efKL2oKtK0-WfmgmfSJfamwdhCNCxsE-uJOxcIQ=.18467bba-1187-4541-896e-3ba1b2b1ab63@github.com>
 <oOdi9t6sNDmcOr7z5pgoIqeQIYJFZ2CnnC8Ix0rue-g=.ea771691-0683-4bbb-9a6c-7a029340d5d6@github.com>
Message-ID: <R5rQjXQp_FUbIqQGvVjM_JnWMjudS8YeLW3WbH3TnZ0=.e7bcb587-854f-4c61-a743-a99a72e40966@github.com>

On Thu, 18 Jan 2024 21:35:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > > 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.

OK, done in the recent version.

> What I tried to point out is the following:
> 
>     1. run `myruntime/bin/jlink` to create `image1` without packaged module
>     2. run `image1/bin/jlink` to create a runtime image will fail
>     3. run `image1/bin/jlink --ignore-modified-runtime` will successfully to create `image2`
> 
> I expect `image2/bin/jlink` should fail creating a runtime image since it's multi-hop. Another scenario: If I modify `image2/conf/net.properties` , `image2/bin/jlink` should fail. In both cases, `image2/bin/jlink --ignore-modified-runtime` will ignore the error and create the runtime image.

This should now be fixed. The stamp file indicating a runtime image created image is now always added.


$ rm -rf ./build/jdk.jlink-runtime && ./build/linux-x86_64-server-release/images/jdk/bin/jlink --output ./build/jdk.jlink-runtime --add-modules jdk.jlink
$ rm -rf ./build/image1/ && ./build/jdk.jlink-runtime/bin/jlink --add-modules jdk.jlink --output  ./build/image1/ --verbose
Linking based on the current run-time image.
'./build/image1' is linked equivalent to using jlink with JDK packaged modules as:
    jlink --add-modules jdk.jlink --output ./build/image1

java.base jrt:/java.base (run-time image)
java.compiler jrt:/java.compiler (run-time image)
jdk.compiler jrt:/jdk.compiler (run-time image)
jdk.internal.opt jrt:/jdk.internal.opt (run-time image)
jdk.jdeps jrt:/jdk.jdeps (run-time image)
jdk.jlink jrt:/jdk.jlink (run-time image)
jdk.zipfs jrt:/jdk.zipfs (run-time image)

Providers:
  jdk.compiler provides com.sun.tools.javac.platform.PlatformProvider used by jdk.compiler
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  jdk.zipfs provides java.nio.file.spi.FileSystemProvider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
  jdk.compiler provides java.util.spi.ToolProvider used by java.base
  jdk.jdeps provides java.util.spi.ToolProvider used by java.base
  jdk.jlink provides java.util.spi.ToolProvider used by java.base
  jdk.compiler provides javax.tools.JavaCompiler used by java.compiler
  jdk.compiler provides javax.tools.Tool not used by any observable module
  jdk.jlink provides jdk.tools.jlink.plugin.Plugin used by jdk.jlink
$ rm -rf ./build/image2/ && ./build/image1/bin/jlink --add-modules jdk.jlink --output  ./build/image2/
Error: Module path to the JDK packaged modules must be specified. Run-time image based linking is not supported as $java.home was already created from a run-time image.
$ rm -rf ./build/image2/ && ./build/image1/bin/jlink --ignore-modified-runtime --add-modules jdk.jlink --output  ./build/image2/
Error: Module path to the JDK packaged modules must be specified. Run-time image based linking is not supported as $java.home was already created from a run-time image.


> `JRTArchive::collectFiles` is the relevant code:
>
>```
>            // add/persist a special, empty file for jdk.jlink so as to support
>            // the single-hop-only run-time image jlink
>            if (singleHop && JDK_JLINK_MODULE.equals(module)) {
>                files.add(createRuntimeImageSingleHopStamp());
>            }
>```

This is now:


if (JDK_JLINK_MODULE.equals(module)) {
       files.add(createRuntimeImageSingleHopStamp());
}


> My intent is to bring up my observation for discussion. The plugin authors are the ones who should decide if the plugin should restore the data from the runtime image to original form. It needs a way to indicate that the transformed data won't persist for this plugin. So far I think FILTER category may be adequate but it may be better to define a new type. This requires some prototype to determine what is the right way.

In the current patch, there is `boolean Plugin::runTimeImageLinkPersistent()` which is exactly what you describe here. The default implementation returns true for `FILTER` or `TRANSFORMER` categories, but this could be explicit for `--vendor-version` et. al. plugins. Unless I misunderstood. I.e. if the `transform()` method is persistent for runtime image based links then it must return `true`. 

> 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.

This has been addressed in the most recent version by this output when performing a run-time image based link:


$ rm -rf ./build/image1/ && ./build/jdk.jlink-runtime/bin/jlink --add-modules jdk.jlink --output  ./build/image1/
Linking based on the current run-time image. Details for reproducing the image using JDK packaged modules are in file runtime-jlink-details.txt or are shown when using --verbose.
$ cat runtime-jlink-details.txt
'./build/image1' is linked equivalent to using jlink with JDK packaged modules as:
    jlink --add-modules jdk.jlink --output ./build/image1


So there is no need to re-create the image with `--verbose`. The file has the details. Please let me know if there are more concerns that need addressing.

More thoughts, @mlchung?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1906205152

From rriggs at openjdk.org  Tue Jan 23 15:18:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 23 Jan 2024 15:18:33 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v5]
In-Reply-To: <RitaZ1Ej-sjgHl4bgPsJLJ5hD-z3ljeWQ0n8vFrquQQ=.2f860079-c0d4-41eb-894a-a78f6f687134@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <RitaZ1Ej-sjgHl4bgPsJLJ5hD-z3ljeWQ0n8vFrquQQ=.2f860079-c0d4-41eb-894a-a78f6f687134@github.com>
Message-ID: <1rmvLpL-NxFuwHXsLqLghFXDNnouQ11MQ4qN1Icb2F8=.0c156875-aadf-46a2-9da2-652bfe6a646f@github.com>

On Fri, 12 Jan 2024 22:41:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove quotes around locale when equal to null

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/text/MessageFormat.java line 1195:

> 1193:             """
> 1194:             MessageFormat [locale: %s, pattern: "%s"]
> 1195:             """.formatted(locale == null ? null : '"'+locale.getDisplayName()+'"', toPattern());

Style wise, operators (like "+") should have spaces around them.

src/java.base/share/classes/java/text/SimpleDateFormat.java line 2433:

> 2431:             """
> 2432:             SimpleDateFormat [locale: %s, pattern: "%s"]
> 2433:             """.formatted(locale == null ? null : '"'+locale.getDisplayName()+'"', toPattern());

Ditto, add spaces around +.

test/jdk/java/text/Format/DateFormat/ToStringTest.java line 59:

> 57:     public void oddValueTest() {
> 58:         String expectedStr =
> 59:                 "SimpleDateFormat [locale: \""+Locale.getDefault().getDisplayName()+"\", pattern: \"MMM d, y\"]\n";

Add spaces around operator +

-------------

PR Review: https://git.openjdk.org/jdk/pull/17355#pullrequestreview-1839039270
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1463432450
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1463433138
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1463434281

From epeter at openjdk.org  Tue Jan 23 15:23:32 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 23 Jan 2024 15:23:32 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v9]
In-Reply-To: <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>
Message-ID: <xdwiUCwY2SrWSC9ZDw7hWycUSPVNLCqKXBK2uYpNd8o=.e73e775a-63f9-405f-b730-73d4b5c42568@github.com>

On Tue, 23 Jan 2024 11:56:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8322768
>  - Modifying comments.
>  - Review comments resolution
>  - Modified code comment for clarity.
>  - Space fixup
>  - Using emulated variable blend E-Core optimized instruction.
>  - Review suggestions incorporated.
>  - Review comments resolutions.
>  - Updating copyright year of modified files.
>  - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.

Ok, I'll just run the testing again, and then I will approve this :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1839057311

From kbarrett at openjdk.org  Tue Jan 23 15:26:33 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 23 Jan 2024 15:26:33 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v6]
In-Reply-To: <VU_oK39fLPRq6d32t1tvSLIHLTOdIItkGsTbXuVcKAM=.2b939eb4-0610-4efb-af28-3c9025100e58@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <VU_oK39fLPRq6d32t1tvSLIHLTOdIItkGsTbXuVcKAM=.2b939eb4-0610-4efb-af28-3c9025100e58@github.com>
Message-ID: <LuF-mEGXN98FB7WBm4hkD2ZVye8WoiTRjcTY4JYOV1k=.6c2d8164-0db6-4377-9e0b-9be9197421ca@github.com>

On Wed, 10 Jan 2024 22:12:40 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 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:
> 
>   Tweak Reference.enqueue memory consistency effects wording

src/java.base/share/classes/java/lang/ref/Reference.java line 508:

> 506:      * Use of this method allows the registered queue's
> 507:      * {@link ReferenceQueue#poll} and {@link ReferenceQueue#remove} methods
> 508:      * to return this reference even though the referent is still strongly

Perhaps s/is still/may still be/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1463145471

From shade at openjdk.org  Tue Jan 23 15:38:27 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 15:38:27 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <l0ZryWB7izCE8t-fOyinka6Tr7VBmIPG3ozMwRwawds=.0ea851f1-6bd9-452f-be8f-3c8b6f300372@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
 <l0ZryWB7izCE8t-fOyinka6Tr7VBmIPG3ozMwRwawds=.0ea851f1-6bd9-452f-be8f-3c8b6f300372@github.com>
Message-ID: <NIA0UkyGG8_czp6o_pluMf82jqIASgSoMn0VvqsHm-E=.513a9090-1807-47ab-ac0f-dc13eb76b641@github.com>

On Tue, 23 Jan 2024 14:42:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Is there any place to document the new keyword or its usage; it does not seem very discoverable just existing in the TEST.ROOT and some tests.

I don't think there is a place to describe keywords, except in the relevant `TEST.ROOT`-s.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1906324934

From kbarrett at openjdk.org  Tue Jan 23 15:42:27 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 23 Jan 2024 15:42:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
Message-ID: <oPKREq27sjqaCbXyHBKGKKHZTvXsQbPiKhOO7U6r3o4=.8c55e1db-b20f-47f1-a84d-b9942454947e@github.com>

On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more overloads

Not a review, just a drive-by comment.
>From the description for this PR: "This is inspired by std::is_constant_evaluated in C++."
I think what is being proposed here is more like gcc's `__builtin_constant_p`.  std::is_constant_evaluated is a different
thing, used to detect evaluation in a manifestly constexpr context.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1906337427

From shade at openjdk.org  Tue Jan 23 15:43:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 15:43:35 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <d_XnS-9KYUYwtoQSTrDB3aNXhjMR67MpLEWIvGdFjzU=.bab81b99-de68-40fd-91fb-06990c185fe1@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

All right, thanks! @lmesnik, I realized I forgot to ask if you had objections to this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1906338893

From sgehwolf at openjdk.org  Tue Jan 23 15:46:04 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 15:46:04 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v15]
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: <adcTJhDKas-O2LFqij08z9RwuozBnZlzaMfx_vdFUDk=.6e567685-5f06-4aee-b570-42d8ce32f356@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 one additional commit since the last revision:

  Rename singleHop field.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/9635ba52..1e69bc9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=13-14

  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 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 shade at openjdk.org  Tue Jan 23 15:51:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 15:51:32 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
Message-ID: <VLOgu0TQu6dryDIVXvENHSU0a8HQfHneezEo_l27ViM=.0815a705-8273-4a1a-8314-ad03289960ae@github.com>

On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more overloads

All right, this is very close :) I now have stylistic comments:

src/hotspot/share/classfile/vmIntrinsics.hpp line 912:

> 910:   do_intrinsic(_getAndSetInt,             jdk_internal_misc_Unsafe,     getAndSetInt_name, getAndSetInt_signature, F_R)       \
> 911:    do_name(     getAndSetInt_name,                                      "getAndSetInt")                                       \
> 912:    do_alias(    getAndSetInt_signature,                                 /*"(Ljava/lang/Object;JI)I"*/ getAndAddInt_signature) \

I don't think we need to do these formatting changes in this PR.

src/hotspot/share/classfile/vmIntrinsics.hpp line 927:

> 925:                                                                                                                               \
> 926:   do_class(jdk_internal_misc_JitCompiler, "jdk/internal/misc/JitCompiler")                                                    \
> 927:   do_intrinsic(_isConstantExpressionZ,    jdk_internal_misc_JitCompiler,isConstantExpression_name, bool_bool_signature, F_S)  \

It would be cleaner to follow the current naming for existing intrinsic:


  do_intrinsic(_isCompileConstant, java_lang_invoke_MethodHandleImpl, isCompileConstant_name, isCompileConstant_signature, F_S) \
   do_name(     isCompileConstant_name,                          "isCompileConstant")                                   \
   do_alias(    isCompileConstant_signature,                      object_boolean_signature)                             \


I.e. rename `isConstantExpression` -> `isCompileConstant`. It clearly communicates that we are not dealing with expressions as arguments, and that we underline this is the (JIT) _compile_ constant, not just a constant expression from JLS 15.28 "Constant Expressions".

Maybe even replace that `MHImpl` method with the new intrinsic.

src/hotspot/share/opto/c2compiler.cpp line 727:

> 725:   case vmIntrinsics::_storeStoreFence:
> 726:   case vmIntrinsics::_fullFence:
> 727:   case vmIntrinsics::_isConstantExpressionZ:

Move this closer to `vmIntrinsics::_isCompileConstant:`, if not outright replace it?

src/hotspot/share/opto/library_call.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Oracle and/or its affiliates. All rights reserved.

Unnecessary update?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17527#pullrequestreview-1839148507
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463490470
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463493124
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463497227
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463497518

From alanb at openjdk.org  Tue Jan 23 15:55:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Jan 2024 15:55:29 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
Message-ID: <02_Q7SYNI7MYYOeNsq1xGPsOY502JbeXfJyvUGZTtZg=.8a6dcf5c-4dfd-4688-97c1-95497b637cd3@github.com>

On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more overloads

Would it be possible to list further examples where this might be used? Asking because I'm wondering about the usability and maintainability of if-then-else code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1906362127

From shade at openjdk.org  Tue Jan 23 16:03:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 16:03:29 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <02_Q7SYNI7MYYOeNsq1xGPsOY502JbeXfJyvUGZTtZg=.8a6dcf5c-4dfd-4688-97c1-95497b637cd3@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
 <02_Q7SYNI7MYYOeNsq1xGPsOY502JbeXfJyvUGZTtZg=.8a6dcf5c-4dfd-4688-97c1-95497b637cd3@github.com>
Message-ID: <cOEBk7SSt0XBpRTe-zh3sQyJQitt0zupWLoOl_diIkE=.10e225fa-c7d3-46e4-ae63-a88f3ab34594@github.com>

On Tue, 23 Jan 2024 15:52:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to list further examples where this might be used? Asking because I'm wondering about the usability and maintainability of if-then-else code.

A similar thing is already used in JDK: https://github.com/openjdk/jdk/blob/2a01c798d346656a0ee3553c0964feab75b5dfb6/src/java.base/share/classes/java/lang/invoke/Invokers.java#L622-L624

Extending this for more common use allows doing things like optimizing `Integer.toString(int)`:


     @Stable
     static final String[] CONST_STRINGS = {"-1", "0", "1"};

     @IntrinsicCandidate
     public static String toString(int i) {
        if (isCompileConstant(i) && (i >= -1) && (i <= 1)) {
            return CONST_STRINGS[i + 1];
        }
        ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1906379544

From dnsimon at openjdk.org  Tue Jan 23 16:47:41 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 Jan 2024 16:47:41 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader
Message-ID: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>

This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.

-------------

Commit messages:
 - load JVMCI with platform class loader

Changes: https://git.openjdk.org/jdk/pull/17520/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323832
  Stats: 227 lines in 8 files changed: 219 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17520/head:pull/17520

PR: https://git.openjdk.org/jdk/pull/17520

From dnsimon at openjdk.org  Tue Jan 23 16:47:42 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 Jan 2024 16:47:42 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader
In-Reply-To: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
Message-ID: <hqH-3BsRlt8sRngLtZdPf-wqKjJyJN8EbEns-Mx_DzU=.73737684-3a2d-4065-bdc2-05b57c1e309c@github.com>

On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.

src/java.base/share/lib/security/default.policy line 166:

> 164: };
> 165: 
> 166: grant codeBase "jrt:/jdk.internal.vm.ci" {

This is required as JVMCI is no longer loaded by the boot loader but should retain all permissions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17520#discussion_r1463601925

From qamai at openjdk.org  Tue Jan 23 16:51:50 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 16:51:50 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v4]
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <MY6QpMPgfD067Q1RsbDGNctZX2WUjonhH_u7yJSz7tc=.c8cc267e-190e-4971-8e67-357ea71823ab@github.com>

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is inspired by `std::is_constant_evaluated` in C++.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  address reviews: rename to isCompileConstant, remove duplication, revert unnecessary changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17527/files
  - new: https://git.openjdk.org/jdk/pull/17527/files/31403d6f..18f7d482

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=02-03

  Stats: 92 lines in 8 files changed: 10 ins; 13 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From qamai at openjdk.org  Tue Jan 23 16:56:29 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 16:56:29 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <VLOgu0TQu6dryDIVXvENHSU0a8HQfHneezEo_l27ViM=.0815a705-8273-4a1a-8314-ad03289960ae@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
 <VLOgu0TQu6dryDIVXvENHSU0a8HQfHneezEo_l27ViM=.0815a705-8273-4a1a-8314-ad03289960ae@github.com>
Message-ID: <aBO8vQc_q75ypSPOAgQ8cO6BNnJJYbDRulyoZzD7Q5o=.207ef435-f8ee-4c00-86fb-5fbb064afce0@github.com>

On Tue, 23 Jan 2024 15:44:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add more overloads
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 927:
> 
>> 925:                                                                                                                               \
>> 926:   do_class(jdk_internal_misc_JitCompiler, "jdk/internal/misc/JitCompiler")                                                    \
>> 927:   do_intrinsic(_isConstantExpressionZ,    jdk_internal_misc_JitCompiler,isConstantExpression_name, bool_bool_signature, F_S)  \
> 
> It would be cleaner to follow the current naming for existing intrinsic:
> 
> 
>   do_intrinsic(_isCompileConstant, java_lang_invoke_MethodHandleImpl, isCompileConstant_name, isCompileConstant_signature, F_S) \
>    do_name(     isCompileConstant_name,                          "isCompileConstant")                                   \
>    do_alias(    isCompileConstant_signature,                      object_boolean_signature)                             \
> 
> 
> I.e. rename `isConstantExpression` -> `isCompileConstant`. It clearly communicates that we are not dealing with expressions as arguments, and that we underline this is the (JIT) _compile_ constant, not just a constant expression from JLS 15.28 "Constant Expressions".
> 
> Maybe even replace that `MHImpl` method with the new intrinsic.

Yes you are right, I have renamed it to `isCompileConstant`.

> src/hotspot/share/opto/c2compiler.cpp line 727:
> 
>> 725:   case vmIntrinsics::_storeStoreFence:
>> 726:   case vmIntrinsics::_fullFence:
>> 727:   case vmIntrinsics::_isConstantExpressionZ:
> 
> Move this closer to `vmIntrinsics::_isCompileConstant:`, if not outright replace it?

I have replaced `MHImpl::isCompileConstant` with the new one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463617016
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463616039

From lmesnik at openjdk.org  Tue Jan 23 16:59:28 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 23 Jan 2024 16:59:28 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <VJuphjAXu0SBIWM9eypa7SLpzUP8SCElmkXBxyCl9kY=.e25ed17d-4b66-41ea-aeb8-1243e2a384fd@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17422#pullrequestreview-1839361504

From shade at openjdk.org  Tue Jan 23 17:06:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 17:06:40 GMT
Subject: Integrated: 8323515: Create test alias "all" for all test roots
In-Reply-To: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
Message-ID: <P2qIBvCejrqrp5pu68twbbsQMrY67dqP2Oir7WMREro=.9cf6c992-8622-4100-a623-0d75f62b44d6@github.com>

On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
> 
> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
> 
> 
> % make test TEST=all
> 
> Test selection 'all', will run:
> * jtreg:test/hotspot/jtreg:all
> * jtreg:test/jdk:all
> * jtreg:test/langtools:all
> * jtreg:test/jaxp:all
> * jtreg:test/lib-test:all
> 
> (...about 6 hours later...)
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>    jtreg:test/langtools:all                           4469  4469     0     0   
>    jtreg:test/jaxp:all                                 513   513     0     0   
>    jtreg:test/lib-test:all                              32    32     0     0   
> ==============================
> TEST FAILURE

This pull request has now been integrated.

Changeset: 8b9bf758
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b9bf758801400e4491326cd4c90fc117b9d97e1
Stats:     49 lines in 5 files changed: 42 ins; 5 del; 2 mod

8323515: Create test alias "all" for all test roots

Reviewed-by: dholmes, alanb, joehw, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/17422

From shade at openjdk.org  Tue Jan 23 17:06:38 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 17:06:38 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
Message-ID: <CQUy1H5or0ZNkZzri_7qizVClqCPPtmlbRDWb5nYL48=.b82ae3cc-598b-4133-a875-4d837808b21e@github.com>

On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since recent work to improve `tier4` performance, we actually test `tier{1,2,3,4}` often, which includes all the tests in current tree. It would be more convenient to just have the `all` test group/alias, so that we can do `make test TEST=all`. This also gives a parallelism / run time benefit, as we do not wait for tests in each tier to complete before moving to next tier. 
>> 
>> Sample run on out-of-the-box Linux x86_64 fastdebug is below. For some environments one also needs to supply a few keywords like `!printer` to skip tests that cannot complete without failure due to misconfiguration. I left the keywords as is to show how would a failing run look. There is also an existing shortcut in build system that allows to run this with `make test-all`.
>> 
>> 
>> % make test TEST=all
>> 
>> Test selection 'all', will run:
>> * jtreg:test/hotspot/jtreg:all
>> * jtreg:test/jdk:all
>> * jtreg:test/langtools:all
>> * jtreg:test/jaxp:all
>> * jtreg:test/lib-test:all
>> 
>> (...about 6 hours later...)
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:all                       6731  6702    29     0 <<
>>>> jtreg:test/jdk:all                                 9962  9951    11     0 <<
>>    jtreg:test/langtools:all                           4469  4469     0     0   
>>    jtreg:test/jaxp:all                                 513   513     0     0   
>>    jtreg:test/lib-test:all                              32    32     0     0   
>> ==============================
>> TEST FAILURE
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catch-all -> All tests

Thank you all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1906520760

From duke at openjdk.org  Tue Jan 23 17:20:29 2024
From: duke at openjdk.org (xxDark)
Date: Tue, 23 Jan 2024 17:20:29 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader
In-Reply-To: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
Message-ID: <Sm2rX0wf19A8q0rRdskZN17JmY9WyGmu-DKBLWtkbPk=.aa86c45e-91aa-4ad9-b729-585ab201ddf5@github.com>

On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.

Hello. I'm not a reviewer but I read through the conversation in JIRA and saw this comment:
 > [~pwoegerer] currently has a Native Image patch where he creates a URLClassLoader whose parent is jdk.internal.loader.ClassLoaders.BOOT_LOADER (retrieved via reflection and use of required --add-exports and --add-opens command line options). That is, he's using the non-delegating approach you mention.

There is zero reason to do this.
Passing `null` as parent class loader would suffice as boot loader just uses `findBootstrapClassOrNull` in `JavaLangAccess` either way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1906515587

From simonis at openjdk.org  Tue Jan 23 17:20:31 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 Jan 2024 17:20:31 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v4]
In-Reply-To: <wpea4DjJRgCr3vaqSScAokbaN4h9O3e9FE-BHhgsfzg=.73c89d8c-b6e3-40ea-91b9-e279d7e0f930@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <wpea4DjJRgCr3vaqSScAokbaN4h9O3e9FE-BHhgsfzg=.73c89d8c-b6e3-40ea-91b9-e279d7e0f930@github.com>
Message-ID: <dYUSTsT0Nstxy0KuEhcg-UiladUNUNVgSZWBAOzy3Dc=.24b631e2-4bd1-4e66-b1b5-cf18bfd2f958@github.com>

On Mon, 22 Jan 2024 22:13:50 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> 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%.
>> 
>> ### JMH results for testPutAll (size = 10000)
>> 
>> before patch:
>> 
>> 
>> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>>   4315291.542 ?(99.9%) 336034.190 ns/op [Average]
>>   (min, avg, max) = (3974688.194, 4315291.542, 4871772.209), stdev = 314326.589
>>   CI (99.9%): [3979257.352, 4651325.731] (assumes normal distribution)
>> 
>> 
>> after patch:
>> 
>> 
>> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>>   3006955.723 ?(99.9%) 271757.969 ns/op [Average]
>>   (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev = 254202.573
>>   CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
>> 
>> 
>> Average time is decreased about 30%.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pass initial size to putAll benchmark map construction

Looks good now.

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17116#pullrequestreview-1839420378

From simonis at openjdk.org  Tue Jan 23 17:20:33 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 Jan 2024 17:20:33 GMT
Subject: RFR: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll [v3]
In-Reply-To: <gRs_lFot4cIGgfVeeOdqNDp6HP6VemUHNd7JLfuWhSc=.19223187-9ea6-4286-97a3-827194843edd@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
 <nj5GGNuqzlht2djMiQxc4oQCgEUq3aGq2lIAR1l3owY=.7b583d5e-95b3-4697-bf7a-b24a3327e165@github.com>
 <KqR1DoTjCohxJZMyc6zOBod4XxbGBjmLmKbRH_cdpYo=.a636b2b6-5747-45f9-9b55-4896ea666e39@github.com>
 <gRs_lFot4cIGgfVeeOdqNDp6HP6VemUHNd7JLfuWhSc=.19223187-9ea6-4286-97a3-827194843edd@github.com>
Message-ID: <291WcebbalpGFke7U5PWpnlNDBAL2bnAYILRuGRUh4k=.72b62747-ded6-4732-a7e5-dd273ebd2a32@github.com>

On Mon, 22 Jan 2024 22:10:44 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:
>> 
>>> 120:     @Benchmark
>>> 121:     public ConcurrentHashMap<Integer, Integer> testConcurrentHashMapPutAll() {
>>> 122:         ConcurrentHashMap<Integer, Integer> map = new ConcurrentHashMap<>();
>> 
>> I think this benchmark could be made more accurate by creating the new, temporary map with the right initial size (i.e. `ConcurrentHashMap<>(nkeys)`) to avoid calls to `tryPresize()` in this setup step.
>
> I updated. The numbers are surprisingly the same. I guess the benchmark compute time is dominated by putAll().

OK, thanks nevertheless.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1463660578

From qamai at openjdk.org  Tue Jan 23 17:21:47 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 17:21:47 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  ident

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17527/files
  - new: https://git.openjdk.org/jdk/pull/17527/files/18f7d482..3ecb2c66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From qamai at openjdk.org  Tue Jan 23 17:21:49 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 17:21:49 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <cOEBk7SSt0XBpRTe-zh3sQyJQitt0zupWLoOl_diIkE=.10e225fa-c7d3-46e4-ae63-a88f3ab34594@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
 <02_Q7SYNI7MYYOeNsq1xGPsOY502JbeXfJyvUGZTtZg=.8a6dcf5c-4dfd-4688-97c1-95497b637cd3@github.com>
 <cOEBk7SSt0XBpRTe-zh3sQyJQitt0zupWLoOl_diIkE=.10e225fa-c7d3-46e4-ae63-a88f3ab34594@github.com>
Message-ID: <BHp0m5yvj70IS5pLXSLTSd1xo0WR1xO_bSNqva1Jt2Q=.535a7353-6602-48b0-bc8a-f13527fc718c@github.com>

On Tue, 23 Jan 2024 16:01:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Would it be possible to list further examples where this might be used? Asking because I'm wondering about the usability and maintainability of if-then-else code.
>
>> Would it be possible to list further examples where this might be used? Asking because I'm wondering about the usability and maintainability of if-then-else code.
> 
> A similar thing is already used in JDK: https://github.com/openjdk/jdk/blob/2a01c798d346656a0ee3553c0964feab75b5dfb6/src/java.base/share/classes/java/lang/invoke/Invokers.java#L622-L624
> 
> Extending this for more common use allows doing things like optimizing `Integer.toString(int)`:
> 
> 
>      @Stable
>      static final String[] CONST_STRINGS = {"-1", "0", "1"};
> 
>      @IntrinsicCandidate
>      public static String toString(int i) {
>         if (isCompileConstant(i) && (i >= -1) && (i <= 1)) {
>             return CONST_STRINGS[i + 1];
>         }
>         ...
> 
> 
> Note how this code would fold away to one of the paths, depending on whether the compiler knows it is a constant or not. Generated-code-wise it is a zero-cost thing :)

@shipilev Thanks a lot for the detailed reviews and suggestions, I hope I have addressed all of them.
@kimbarrett TIL about that builtin, updated the PR description to mention that instead. Thanks very much.
@AlanBateman Another potential usage I mentioned in the JBS issue is that `GlobalSession` is noncloseable, but there is no way for the accessor to know that without doing a checkcast. Using this we can eliminate the check if the session is statically known to be a global session without imposing additional checks on other kinds of memory sessions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1906549618

From shade at openjdk.org  Tue Jan 23 17:50:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 17:50:31 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
Message-ID: <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>

On Tue, 23 Jan 2024 17:21:47 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ident

A few more stylistic comments :)

Still thinking the better home for these might be just `jdk.internal.misc.VM`... But I would not insist, if others are happy.

src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 56:

> 54:      */
> 55:     @IntrinsicCandidate
> 56:     public static boolean isCompileConstant(boolean expr) {

Here and in other places: probably not `expr`, but just `val` or something?

src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 119:

> 117:      * @see #isCompileConstant(boolean)
> 118:      */
> 119:     @IntrinsicCandidate

Note how the Java entry for MH intrinsic we have replaced had `@Hidden`. These methods should have `@Hidden` too then? Probably applies to other entries too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17527#pullrequestreview-1839475907
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463705907
PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463703771

From shade at openjdk.org  Tue Jan 23 17:50:33 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 17:50:33 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v3]
In-Reply-To: <cOEBk7SSt0XBpRTe-zh3sQyJQitt0zupWLoOl_diIkE=.10e225fa-c7d3-46e4-ae63-a88f3ab34594@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <H4WQ9nzjmTAEiUfeMcTOErT_l4biVMGsAYLk2vk2fD4=.043c6f68-515b-4c43-b310-43b65567de61@github.com>
 <02_Q7SYNI7MYYOeNsq1xGPsOY502JbeXfJyvUGZTtZg=.8a6dcf5c-4dfd-4688-97c1-95497b637cd3@github.com>
 <cOEBk7SSt0XBpRTe-zh3sQyJQitt0zupWLoOl_diIkE=.10e225fa-c7d3-46e4-ae63-a88f3ab34594@github.com>
Message-ID: <gQTZlCIJo8GP6x_D3gZPaA5LV8RLcBUhqCtg_ix_EF0=.d757339a-9bb1-4873-accc-32b8c35c029e@github.com>

On Tue, 23 Jan 2024 16:01:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Would it be possible to list further examples where this might be used? Asking because I'm wondering about the usability and maintainability of if-then-else code.
>
>> Would it be possible to list further examples where this might be used? Asking because I'm wondering about the usability and maintainability of if-then-else code.
> 
> A similar thing is already used in JDK: https://github.com/openjdk/jdk/blob/2a01c798d346656a0ee3553c0964feab75b5dfb6/src/java.base/share/classes/java/lang/invoke/Invokers.java#L622-L624
> 
> Extending this for more common use allows doing things like optimizing `Integer.toString(int)`:
> 
> 
>      @Stable
>      static final String[] CONST_STRINGS = {"-1", "0", "1"};
> 
>      @IntrinsicCandidate
>      public static String toString(int i) {
>         if (isCompileConstant(i) && (i >= -1) && (i <= 1)) {
>             return CONST_STRINGS[i + 1];
>         }
>         ...
> 
> 
> Note how this code would fold away to one of the paths, depending on whether the compiler knows it is a constant or not. Generated-code-wise it is a zero-cost thing :)

> @shipilev Thanks a lot for the detailed reviews and suggestions, I hope I have addressed all of them. 

Sure thing, I just effectively merged my draft implementation into yours :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1906602556

From jvernee at openjdk.org  Tue Jan 23 18:27:31 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 23 Jan 2024 18:27:31 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong
In-Reply-To: <eF4H-n79i2jg3A1RtihDJLhrDGrDFVPIXSEKKD8KLIM=.b1aa9abb-5ff5-40d3-8b2a-6b053ddbef51@github.com>
References: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
 <sPZzoVJ1mJYKNCf5EW69FVw22yZw4ZLzmRa79e4rg_E=.69ab3b67-767c-4485-8a0d-1f0fa9c02546@github.com>
 <Y909Cm6M5nnx9oXb4Utjr5Kh-tbyFVEOuu2FuaBtpKw=.01277bfa-f509-40ac-8970-c81c00bf636d@github.com>
 <eF4H-n79i2jg3A1RtihDJLhrDGrDFVPIXSEKKD8KLIM=.b1aa9abb-5ff5-40d3-8b2a-6b053ddbef51@github.com>
Message-ID: <8DFnNb3KsE4jKM-Aaln4A8tKaJpXmDWfvEODAKXQD2I=.246523c3-6a11-4d9e-9ae7-6db0117aa5ea@github.com>

On Tue, 23 Jan 2024 14:30:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Good idea. Thanks
>
> Should we make these unaligned access modes throw ISE like before, when the given index is unaligned?

You mean `get` and `set`? They should never throw, as unaligned access is fine. For other access modes, we can never guarantee that an access is aligned, so UOE is appropriate. (IIRC this is mandated by existing spec. I'll try to find it again)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16681#discussion_r1463769755

From jvernee at openjdk.org  Tue Jan 23 18:40:30 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 23 Jan 2024 18:40:30 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong
In-Reply-To: <l7jVhuR5JNdh41bqEcYQSXvwtEW5WBJyfrTV06iR_cc=.c78ddfad-5920-4c20-aab8-a65fb13a1762@github.com>
References: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
 <l7jVhuR5JNdh41bqEcYQSXvwtEW5WBJyfrTV06iR_cc=.c78ddfad-5920-4c20-aab8-a65fb13a1762@github.com>
Message-ID: <H7mp___18ZEknAoY91g91GWowsxEUF5tT1imszwKaME=.abd903e7-0a3b-4165-be59-6375480a3b24@github.com>

On Tue, 23 Jan 2024 14:43:24 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also curious, is there any documentation (like JVMS) that allows JVMs to make no offset into byte arrays aligned for larger access? Would be helpful if we can have a reference here.

There is simply no guarantee in the JVMS that array elements are aligned more than their size. So, the public API may not assume that they are, since it needs to be implementable by an arbitrary JVM that is JVMS compliant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1906687425

From jlu at openjdk.org  Tue Jan 23 18:46:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 18:46:37 GMT
Subject: RFR: JDK-6503196: API doc for DecimalFormat::getMaximumIntegerDigits
 is unclear
Message-ID: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>

Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.

When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.

Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.

Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/17541/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6503196
  Stats: 47 lines in 1 file changed: 17 ins; 22 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17541/head:pull/17541

PR: https://git.openjdk.org/jdk/pull/17541

From jlaskey at openjdk.org  Tue Jan 23 18:53:39 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 23 Jan 2024 18:53:39 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v8]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <Blm-6qX2Na94tV7TnvRdunU_t0YLB-Oip7ZIKtttKu4=.db241d1e-507f-4b05-bb0d-260fab82e9ac@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

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/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/2eb5c194..eba05c2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=06-07

  Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From dnsimon at openjdk.org  Tue Jan 23 19:16:49 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 Jan 2024 19:16:49 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
Message-ID: <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>

> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  use null to denote boot class loader as delegation parent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17520/files
  - new: https://git.openjdk.org/jdk/pull/17520/files/e7d5801a..1642276e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17520&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17520&range=00-01

  Stats: 8 lines in 1 file changed: 1 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17520/head:pull/17520

PR: https://git.openjdk.org/jdk/pull/17520

From dnsimon at openjdk.org  Tue Jan 23 19:16:50 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 Jan 2024 19:16:50 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader
In-Reply-To: <Sm2rX0wf19A8q0rRdskZN17JmY9WyGmu-DKBLWtkbPk=.aa86c45e-91aa-4ad9-b729-585ab201ddf5@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <Sm2rX0wf19A8q0rRdskZN17JmY9WyGmu-DKBLWtkbPk=.aa86c45e-91aa-4ad9-b729-585ab201ddf5@github.com>
Message-ID: <V9FJI5wL5kBtIJjHpfRF1KsYU2xadq5orc7i2B4Lqyg=.705d600a-6fc9-4db3-9c1b-28f2f7e91e40@github.com>

On Tue, 23 Jan 2024 17:00:20 GMT, xxDark <duke at openjdk.org> wrote:

> Passing `null` as parent class loader would suffice as boot loader just uses `findBootstrapClassOrNull` in `JavaLangAccess` either way

Thanks! I've simplified the test accordingly: 1642276ea22a5d789e01a5ecb1059d8c5c8be284

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1906753878

From jlu at openjdk.org  Tue Jan 23 19:22:44 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 19:22:44 GMT
Subject: RFR: JDK-8321545: Override toString() for Format subclasses [v6]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <XXGFRioj4vvnPv38tYJQ3sqr0k3jPRDID0hp9-dYQg0=.0bb3c660-afc9-4545-b030-f779e35d27bf@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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 11 additional commits since the last revision:

 - reflect Rogers comments: style changes
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - remove quotes around locale when equal to null
 - replace 'None' with 'null' for applicable classes
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - swap placement of decimal pattern and compact patterns. Expand on tests
 - add unit tests
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - account for null locale for SDF through deserialization
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - ... and 1 more: https://git.openjdk.org/jdk/compare/9baaa352...d65cbcd1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/70e0a175..d65cbcd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17355&range=04-05

  Stats: 14587 lines in 430 files changed: 7332 ins; 5481 del; 1774 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

PR: https://git.openjdk.org/jdk/pull/17355

From psandoz at openjdk.org  Tue Jan 23 20:04:29 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 23 Jan 2024 20:04:29 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
Message-ID: <LJ1FdhkTa6IjZDirNhY5J7C08VSzuQjbYW5srsBanmA=.ce805ea5-3260-4c74-939b-06656ff6493f@github.com>

On Tue, 23 Jan 2024 17:21:47 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ident

src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 32:

> 30:  * Just-in-time-compiler-related queries
> 31:  */
> 32: public class JitCompiler {

An alternative name and location is `jdk.internal.vm.ConstantSupport` with initial class doc:

Defines methods to test if a value has been evaluated to a compile-time constant value by the HotSpot VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1463926393

From forax at univ-mlv.fr  Tue Jan 23 20:04:28 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 23 Jan 2024 21:04:28 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Monday, January 22, 2024 10:06:27 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> The flags are in sync with the implementation because the only way to create a
>> Gatherer if through the factory methods and those factory methods (and only
>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>> user.

> But I presume this also requires to have a `int characteristics()`-method on the
> Gatherer interfacewhich means that users who are not using the factory methods
> will have full possibility of not only returning the flags, but returning any
> int.

The current implementation suffers the same kind of issue, it's easy to write a mutable Gatherer and change the functions after creation, worst, right in the middle of a call to stream.gather(...). 

Perhaps the Gatherer interface should be sealed ? We did not have that option during the 1.8 timeframe, when the Collector API was created. 

>> The stream implementation has a whole mechanism in place to propagate/preverse
>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>> good citizen and works seemlessly with the other intermediary operations.

> I can see where you're coming from here, but to me, adding API surface needs to
> pull its weight.
> In this case I wasn't convinced that it did, hence we're having this
> conversation. \uD83D\uDE42

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Monday, 22 January 2024 19:56
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Monday, January 22, 2024 4:22:11 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> Hi R?mi,

> Hello,

>> For instance, stateless is neither recessive nor dominant, since the composition
>> of two stateless operations is only ever stateless if they both are greedy as
>> well: [
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>> |
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>> ]

> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
> the combination is ad-hoc, reflecting the characterristics is enough.

>> So even if making it represented as ints (more like Spliterator, rather than
>> Collector) makes things faster, it's still both work to track, propagate, and
>> also becomes a side-channel that needs to remain in sync with the actual
>> implementation of the logic.

> The flags are in sync with the implementation because the only way to create a
> Gatherer if through the factory methods and those factory methods (and only
> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
> should not be able to set those flags. Only the flags KEEP_* are settable by a
> user.

>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>> performance bug/inefficiency in an of itself as it would be faster to do
>> someCollection.size().

> The stream implementation has a whole mechanism in place to propagate/preverse
> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
> this mechanism seems a little off topic. I would prefer the Gatherer to be a
> good citizen and works seemlessly with the other intermediary operations.

> Cheers,
> ?

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Monday, 22 January 2024 19:56
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Monday, January 22, 2024 4:22:11 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> Hi R?mi,

> Hello,

>> For instance, stateless is neither recessive nor dominant, since the composition
>> of two stateless operations is only ever stateless if they both are greedy as
>> well: [
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>> |
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>> ]

> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
> the combination is ad-hoc, reflecting the characterristics is enough.

>> So even if making it represented as ints (more like Spliterator, rather than
>> Collector) makes things faster, it's still both work to track, propagate, and
>> also becomes a side-channel that needs to remain in sync with the actual
>> implementation of the logic.

> The flags are in sync with the implementation because the only way to create a
> Gatherer if through the factory methods and those factory methods (and only
> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
> should not be able to set those flags. Only the flags KEEP_* are settable by a
> user.

>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>> performance bug/inefficiency in an of itself as it would be faster to do
>> someCollection.size().

> The stream implementation has a whole mechanism in place to propagate/preverse
> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
> this mechanism seems a little off topic. I would prefer the Gatherer to be a
> good citizen and works seemlessly with the other intermediary operations.

>> Cheers,
>> ?

> regards,
> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Saturday, 20 January 2024 17:40
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Thursday, January 18, 2024 5:14:38 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>> both gatherers keep it sorted.

>>> That is unfortunately not the case. That would presume that you can implement
>>> the composition such that it can preserve all the common flags. Some flags
>>> could be "dominant" and some "recessive" to use genetics nomenclature.

>> Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not
>> the characteristics of the Gatherer which can have the corresponding "dominant"
>> flag, GREEDY, in this case.
>> And the same for sequential, the flag should be PARALELIZABLE and not
>> SEQUENTIAL.

>> The idea is that the Gatherer characteristics can have the same bit set at the
>> same position as the stream op flags (as defined by StreamOpFlag).
>> So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED
>> is in position 3.
>> For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit
>> (using XOR) when we want to extract the stream op flags from the
>> characteristics

>> All the factory methods call the generic of() with a combination of
>> PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY,
>> KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be
>> raised).

>> In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for
>> our two new states PARALELIZABLE and STATELESS, so no problem here (technically
>> we can also reuse positions of the Spliterator characteristic given that those
>> flags are masked before being sent to the GathererOp super constructor).

>> The way to transform a Gatherer characteristics op to a stream flags op is to
>> flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags
>> but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask
>> to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

>> public static int toOpFlags ( int characteristics ) {
>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>> STREAM_OP_MASK ;
>> }

>> see below for a full script.

>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>> and i do not understand how it can make the other operations slower.

>>> Extra invocations, extra storage, and extra composition overhead is not free.
>>> Since Stream is one-shot you need to include the construction cost with the
>>> execution cost. For something like an empty Stream construction cost scan be
>>> 90+% of the total costs.

>> If you create a Gatherer, the characteristics is a constant (so the validity
>> check is removed, it's just a mask and a test) so the result of calling
>> toOpFlags() is a constant too.

>> If the factory method is not inlined, the cost is 3 bitwise operations which is
>> I believe faster than the "instanceof Greedy" used in the current code.

>>> Cheers,
>>> ?

>> regards,
>> R?mi

>> ---
>> public class GathererFlag {
>> // cut and paste from StreamOpFlag
>> /**
>> * The bit pattern for setting/injecting a flag.
>> */
>> private static final int SET_BITS = 0b01 ;

>> /**
>> * The bit pattern for clearing a flag.
>> */
>> private static final int CLEAR_BITS = 0b10 ;

>> /**
>> * The bit pattern for preserving a flag.
>> */
>> private static final int PRESERVE_BITS = 0b11 ;

>> private static int position ( int opFlagSet ) {
>> return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ;
>> }

>> private static final int DISTINCT_POSITION = position ( StreamOpFlag .
>> IS_DISTINCT );
>> private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED
>> );
>> private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED );

>> private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag .
>> IS_SHORT_CIRCUIT );
>> private static final int STATELESS_POSITION = 14 ;
>> private static final int PARELLIZABLE_POSITION = 15 ;

>> public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1
>> );
>> public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 );
>> public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 );

>> public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 );
>> public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 );
>> public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 );

>> private static final int SHORT_CIRCUIT_MASK = SET_BITS << (
>> SHORT_CIRCUIT_POSITION << 1 );

>> // no GREEDY here
>> private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS |
>> KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ;

>> private static final int STREAM_OP_MASK =
>> (( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) |
>> GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ;

>> public static String toString ( int characteristics ) {
>> return Stream . of ( characteristics )
>> .< String >mapMulti(( f , consumer ) -> {
>> if (( f & PARELLIZABLE ) == PARELLIZABLE ) {
>> consumer .accept( "PARELLIZABLE" );
>> }
>> if (( f & STATELESS ) == STATELESS ) {
>> consumer .accept( "STATELESS" );
>> }
>> if (( f & GREEDY ) == GREEDY ) {
>> consumer .accept( "GREEDY" );
>> }
>> if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) {
>> consumer .accept( "KEEP_DISTINCT" );
>> }
>> if (( f & KEEP_SORTED ) == KEEP_SORTED ) {
>> consumer .accept( "KEEP_SORTED" );
>> }
>> if (( f & KEEP_SIZED ) == KEEP_SIZED ) {
>> consumer .accept( "KEEP_SIZED" );
>> }
>> })
>> .collect( Collectors . joining ( ", " ));
>> }

>> public static int toOpFlags ( int characteristics ) {
>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>> STREAM_OP_MASK ;
>> }

>> public static String toOpFlagsString ( int opFlags ) {
>> return Arrays . stream ( StreamOpFlag . values ())
>> .map( op -> {
>> if ( op .isPreserved( opFlags )) {
>> return "preserved " + op ;
>> }
>> if ( op .isCleared( opFlags )) {
>> return "cleared " + op ;
>> }
>> if ( op .isKnown( opFlags )) {
>> return "set " + op ;
>> }
>> return "?? " + op ;
>> })
>> .collect( Collectors . joining ( ", " ));
>> }

>> void main () {
>> var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT |
>> KEEP_SORTED | KEEP_SIZED ;
>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics )));

>> var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ;
>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 )));
>> }
>> }

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Thursday, 18 January 2024 16:17
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>> <psandoz at openjdk.java.net>
>>>> Sent: Thursday, January 18, 2024 3:36:07 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>>>> others will want to be able to have INJECT-flags, and then people might have
>>>> different opinions w.r.t. the default should be to clear all flags etc.

>>>> And that's even before one looks at the composition-part of it, what are the
>>>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>>>> set of flags always approaches 0)

>>>> I spent quite a bit of time on this and in the end tracking all this info, and
>>>> making sure that the flags of implementations correspond to the actual
>>>> behavior, just ended up costing performance for most streams and introduced an
>>>> extra dimension to creation and maintenance which I had a hard time justifying.

>>> It can be a slippery slope if we were designing from the ground up but the
>>> stream implementation already exists and SORTED, DISTINCT and SIZED are the
>>> flags that are already tracked by the current implementation.

>>> Currently only SHORT_CIRCUIT is set (if not greedy),
>>> see [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
>>> ]

>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>> both gatherers keep it sorted.

>>>> Making specific, rare, combinations of operations faster at the expense of
>>>> making 99% of all others slower is a hard pill for most to swallow.

>>> I suppose that if those flags already exist, it's because they have a purpose
>>> and i do not understand how it can make the other operations slower.

>>>> Cheers,
>>>> ?

>>> regards,
>>> R?mi

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>> Sent: Thursday, 18 January 2024 10:28
>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>> <psandoz at openjdk.java.net>
>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>> propagated

>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>>>> <core-libs-dev at openjdk.java.net>
>>>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> Hi R?mi,

>>>>> You can find some of my benches here: [
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>>>> |
>>>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>>>> ]

>>>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>>>> didn't end up worth it when looking at the bench results over a wide array of
>>>>> stream sizes and number of operations.

>>>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>>>> KEEP_DISTINCT and KEEP_SIZED,
>>>> all of them say that if the stream was sorted/distinct/sized then the stream
>>>> returned by a call to gather() is still sorted (with the same comparator),
>>>> distinct or sized.

>>>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>>>> windowFixed is KEEP_DISTINCT.

>>>> [CC Paul, so he can correct me if i'm saying something stupid]

>>>> Now for the benchmarks, it depends what you want to measure, benchmarking
>>>> streams is tricky. This is what i know about benchmarking streams.
>>>> First, the JIT has two ways to profile types at runtime,
>>>> Either a method takes a function as parameter
>>>> void map(Function function) {
>>>> function.apply(...)
>>>> }
>>>> and when map is called with a subtype of Function, the JIT will propagate the
>>>> exact type when map is inlined,
>>>> Or a method use a field
>>>> class Op {
>>>> Function function;

>>>> void map() {
>>>> function.apply(...)
>>>> }
>>>> }
>>>> in that case, the VM records the profile of function.apply() and if there are
>>>> more than two different profiles, the VM declare profile poluttion and do not
>>>> try to optimize.

>>>> The Stream implementation tries very hard to use only parameters instead of
>>>> fields, that's why it does not use classical Iterator that are pull iterator (a
>>>> filter iterator requires a field) but a Spliterator which is a push iterator,
>>>> the element is sent as parameter of the consumer.That's also why collect does
>>>> not use the builder pattern (that accumulate values in fields) but a Collector
>>>> that publish the functions to be called as parameter.

>>>> Obvisously, this is more complex than that, a Collector stores the functions in
>>>> fields so it should not work well but the implementation uses a record that
>>>> plays well with escape analysis. Escape analysis see the fields of an instance
>>>> as parameters so the functions of a Collector are correctly propagated (if the
>>>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>>>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>>>> are routinely fully inlined with the intermediate operation of a stream.

>>>> In your tests, i've not seen comparaisons between an existing method like map()
>>>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>>>> where the characteristics KEEP_* have an impact and their equivalent using a
>>>> Gatherer.

>>>>> Cheers,
>>>>> ?

>>>> regards,
>>>> R?mi

>>>>> Viktor Klang
>>>>> Software Architect, Java Platform Group
>>>>> Oracle

>>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>>>> <forax at univ-mlv.fr>
>>>>> Sent: Wednesday, 17 January 2024 16:48
>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>> Subject: Gatherer: spliterator characteristics are not propagated
>>>>> While doing some benchmarking of the Gatherer API, i've found that the
>>>>> characteristics of the spliterator was not propagated by the method
>>>>> Stream.gather() making the stream slower than it should.

>>>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>>>> that this intermediate operation keep the size, which is important if the
>>>>> terminal operation is toList() because if the size is known, toList() will
>>>>> presize the List and avoid the creation of an intermediary ArrayList.

>>>>> See [
>>>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>>>> |
>>>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>>>> ]

>>>>> I think that adding a way to propagate the spliterator characteristics through a
>>>>> Gatherer would greatly improve the performance of commons streams (at least all
>>>>> the ones that end with a call to toList).

>>>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>>>> something and if improving the performance is something worth changing the API.

>>>>> regards,
>>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240123/4f13cdce/attachment-0001.htm>

From liach at openjdk.org  Tue Jan 23 20:35:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Jan 2024 20:35:29 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong
In-Reply-To: <8DFnNb3KsE4jKM-Aaln4A8tKaJpXmDWfvEODAKXQD2I=.246523c3-6a11-4d9e-9ae7-6db0117aa5ea@github.com>
References: <zKoYh_ZFY0WejtXUErNgnHcoR2M-m_T54IuIpw0-cWI=.cd849a2a-f36e-4cef-9477-4dd3fbce6365@github.com>
 <sPZzoVJ1mJYKNCf5EW69FVw22yZw4ZLzmRa79e4rg_E=.69ab3b67-767c-4485-8a0d-1f0fa9c02546@github.com>
 <Y909Cm6M5nnx9oXb4Utjr5Kh-tbyFVEOuu2FuaBtpKw=.01277bfa-f509-40ac-8970-c81c00bf636d@github.com>
 <eF4H-n79i2jg3A1RtihDJLhrDGrDFVPIXSEKKD8KLIM=.b1aa9abb-5ff5-40d3-8b2a-6b053ddbef51@github.com>
 <8DFnNb3KsE4jKM-Aaln4A8tKaJpXmDWfvEODAKXQD2I=.246523c3-6a11-4d9e-9ae7-6db0117aa5ea@github.com>
Message-ID: <PVYsahySjEiDXukPLlZFvXx4LVWW7RMxC5Y70XA0gm4=.a171b3fe-e979-4c0c-9d19-ad9fb0ac8dd4@github.com>

On Tue, 23 Jan 2024 18:24:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Should we make these unaligned access modes throw ISE like before, when the given index is unaligned?
>
> You mean `get` and `set`? They should never throw, as unaligned access is fine. For other access modes, we can never guarantee that an access is aligned, so UOE is appropriate. (IIRC this is mandated by existing spec. I'll try to find it again)
> 
> P.S. See e.g. the javadoc of `VarHandle::getVolatile`:
> 
>>     @throws UnsupportedOperationException if the access mode is unsupported for this VarHandle.
> 
> P.P.S. Also remembering that we can not have any implementation for the access methods, in order for `isAccessModeSupported` to work correctly. And the logic that handles unsupported methods throws UOE (see `VarForm::getMemberName`)

Good point, so previous behavior of throwing ISE is out of spec

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16681#discussion_r1463958704

From naoto at openjdk.org  Tue Jan 23 21:44:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jan 2024 21:44:27 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v8]
In-Reply-To: <Blm-6qX2Na94tV7TnvRdunU_t0YLB-Oip7ZIKtttKu4=.db241d1e-507f-4b05-bb0d-260fab82e9ac@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <Blm-6qX2Na94tV7TnvRdunU_t0YLB-Oip7ZIKtttKu4=.db241d1e-507f-4b05-bb0d-260fab82e9ac@github.com>
Message-ID: <XlqVjLPl-GBZYoma_bQLsRUk9fM5akMbwD6_oI-4RL8=.f6589215-0807-4887-8d52-8a6b33097bfb@github.com>

On Tue, 23 Jan 2024 18:53:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes

src/java.base/share/classes/java/lang/String.java line 4229:

> 4227:      *     <th scope="row">{@code \u005Cu...uXXXX}</th>
> 4228:      *     <td>unicode escape</td>
> 4229:      *     <td>single character UTF-16 equivalent</td>

It would be clearer to have "single UTF-16 code unit equivalent" as the translation explanation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1464029302

From naoto at openjdk.org  Tue Jan 23 22:16:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jan 2024 22:16:27 GMT
Subject: RFR: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
In-Reply-To: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
References: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
Message-ID: <LU_67A7Ms9cjZfPTRSVLnlbvCJC1JOFfhH1kbzcBdRM=.f5a4854e-d754-436f-97c4-7e7fa632c292@github.com>

On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.
> 
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.
> 
> Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.
> 
> Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17541#pullrequestreview-1840039217

From jlu at openjdk.org  Tue Jan 23 22:23:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 22:23:34 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
Message-ID: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>

On Fri, 19 Jan 2024 23:30:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implNote to Javadoc for toPattern().

Hi @archiecobbs, left some initial comments.

But I think the logic is sound so far. Quote all quotable characters that need to be quoted, at the MessageFormat level this is simply opening and closing bracket, which you accomplished with the 2 pass copyAndQuoteBraces method. The goal is to create a resultant String that can create a MessageFormat that formats equivalently as the original, (even if calling toPattern() on both MessageFormats returns different String values).

Let's also try and get the CSR approved first.

src/java.base/share/classes/java/text/MessageFormat.java line 1:

> 1: /*

For this file, please also bump the latter copyright year to 2024.

src/java.base/share/classes/java/text/MessageFormat.java line 556:

> 554:      * does not necessarily equal the previously applied pattern.
> 555:      *
> 556:      * @implNote The string returned by this method can be used to create

Hmm, I'm not sure about the current note, because its not true in all cases (for example, some unknown subclass of Format). Maybe @naotoj has thoughts?

src/java.base/share/classes/java/text/MessageFormat.java line 585:

> 583:                     if (fmt instanceof DecimalFormat) {
> 584:                         result.append(",number");
> 585:                         subformatPattern = ((DecimalFormat)fmt).toPattern();

Could use pattern matching `instanceof` here and in the other instances, but I understand if you're trying to stay consistent with the existing code.

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 56:

> 54: 
> 55:     private static final int NUM_RANDOM_TEST_CASES = 1000;
> 56:     private static final int MAX_FORMAT_NESTING = 3;

Can you add a comment defining `MAX_FORMAT_TESTING`, might not be immediately understood without further investigation

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 90:

> 88:         // A few more test cases from the PR#17416 discussion
> 89:         testRoundTrip(new MessageFormat("Test: {0,number,foo'{'#.00}"));
> 90:         testRoundTrip(new MessageFormat("Test: {0,number,foo'}'#.00}"));

Can we add some more concrete test cases, for example, escaped quotes within a MessageFormat pattern (represented by doubled single quotes). 

Another funny case is something like a MessageFormat created by `"{0,number,' abc }'' ' 0.00}"` which becomes `"{0,number, abc '}'''  #0.00}"` after created from the value returned by toPattern() from the first MessageFormat. The Strings appear really different but format equivalently, it would be nice to have suspicious cases like these explicitly defined.

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 96:

> 94:     @ParameterizedTest
> 95:     @MethodSource("testCases")
> 96:     public void testRoundTrip(MessageFormat format1) {

Can we also include the original String pattern that created format1, to help with debugging. I find myself wondering what the original String was.

Since technically, the full round trip is _pattern string -> MessageFormat1 -> pattern string -> MessageFormat2_

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 154:

> 152:     // Generate a "random" MessageFormat. We do this by creating a MessageFormat with "{0}" placeholders
> 153:     // and then substituting in random DecimalFormat, DateFormat, and ChoiceFormat subformats. The goal here
> 154:     // is to avoid using pattern strings to construct formats, because they're what we're trying to check.

Can you add a general example of a randomly generated MessageFormat in the comments, (I know they vary by quite a lot), but it would be hard for someone to piece if together without digging into the code. And unfortunately the current toString() of MessageFormat is not implemented, so although JUnit prints the MessageFormat out, it's just gibberish.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17416#pullrequestreview-1840037706
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464059010
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464059073
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464059360
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464060206
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464061279
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464062599
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464063513

From jlu at openjdk.org  Tue Jan 23 22:25:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 22:25:41 GMT
Subject: Integrated: JDK-8321545: Override toString() for Format subclasses
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <XcTpILSMk7F7luBsSBtJNBf1OWoCAPGf1zS-JgNwnEk=.9ba6e149-6f77-4823-9237-88ddbc191169@github.com>

On Wed, 10 Jan 2024 21:05:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

This pull request has now been integrated.

Changeset: 96607df7
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96607df7f055a80d56ea4c19f3f4fcb32838b1f8
Stats:     419 lines in 12 files changed: 412 ins; 0 del; 7 mod

8321545: Override toString() for Format subclasses

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/17355

From iris at openjdk.org  Tue Jan 23 22:27:26 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 Jan 2024 22:27:26 GMT
Subject: RFR: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
In-Reply-To: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
References: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
Message-ID: <3znCjA6Ng6Fi7KqCFMw0PITckIqZLJEm9r_7Y95GGIM=.48b96ae7-4ff9-4a68-ba83-795a75d67b3e@github.com>

On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.
> 
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.
> 
> Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.
> 
> Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17541#pullrequestreview-1840051983

From qamai at openjdk.org  Tue Jan 23 22:44:28 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 22:44:28 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
Message-ID: <vgDkJF9ZKMLwCab_YQZEXs8VHrgwNbyhVOVC1bJ0W-E=.7de2dc69-d2fb-44ab-a38f-1ba2a893d4ef@github.com>

On Tue, 23 Jan 2024 17:40:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ident
>
> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 119:
> 
>> 117:      * @see #isCompileConstant(boolean)
>> 118:      */
>> 119:     @IntrinsicCandidate
> 
> Note how the Java entry for MH intrinsic we have replaced had `@Hidden`. These methods should have `@Hidden` too then? Probably applies to other entries too.

I don't understand why this needs to be `@Hidden`, the javadoc says that a function annotated with `@Hidden` is omitted from the stacktraces. This function does not call anything so what is the point of hiding it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464081953

From qamai at openjdk.org  Tue Jan 23 22:49:28 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 22:49:28 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
Message-ID: <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>

On Tue, 23 Jan 2024 17:42:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ident
>
> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 56:
> 
>> 54:      */
>> 55:     @IntrinsicCandidate
>> 56:     public static boolean isCompileConstant(boolean expr) {
> 
> Here and in other places: probably not `expr`, but just `val` or something?

I think of this as an expression that is always evaluated to the same value. The value itself is not interesting, it is the set of values that this expression can take that we are talking about.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464085126

From qamai at openjdk.org  Tue Jan 23 22:52:27 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 23 Jan 2024 22:52:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <LJ1FdhkTa6IjZDirNhY5J7C08VSzuQjbYW5srsBanmA=.ce805ea5-3260-4c74-939b-06656ff6493f@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <LJ1FdhkTa6IjZDirNhY5J7C08VSzuQjbYW5srsBanmA=.ce805ea5-3260-4c74-939b-06656ff6493f@github.com>
Message-ID: <81tjQoutCZRej3wZAnPDJIq31hz7D7tbiJLWyWpXXv0=.5786bc11-7aa2-4290-a1d5-37c82452ed41@github.com>

On Tue, 23 Jan 2024 20:01:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ident
>
> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 32:
> 
>> 30:  * Just-in-time-compiler-related queries
>> 31:  */
>> 32: public class JitCompiler {
> 
> An alternative name and location is `jdk.internal.vm.ConstantSupport` with initial class doc:
> 
> Defines methods to test if a value has been evaluated to a compile-time constant value by the HotSpot VM.

That sounds like a better name for the class, although I think `jdk.internal.misc` is more suitable than `jdk.internal.vm`. Do you have any preference? Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464087772

From naoto at openjdk.org  Tue Jan 23 23:03:28 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jan 2024 23:03:28 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
Message-ID: <SLbD3ysQl7WD43ouzjqKykKOCZLmSmH7ImiLau9aiaU=.c7570102-0fdc-421e-b0e1-a84005227324@github.com>

On Tue, 23 Jan 2024 22:13:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implNote to Javadoc for toPattern().
>
> src/java.base/share/classes/java/text/MessageFormat.java line 556:
> 
>> 554:      * does not necessarily equal the previously applied pattern.
>> 555:      *
>> 556:      * @implNote The string returned by this method can be used to create
> 
> Hmm, I'm not sure about the current note, because its not true in all cases (for example, some unknown subclass of Format). Maybe @naotoj has thoughts?

Yes, my comment to the CSR was to explain the default implementation as the `@implNote`. Making it explicit would be helpful to readers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464096885

From acobbs at openjdk.org  Tue Jan 23 23:15:30 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Jan 2024 23:15:30 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
Message-ID: <dY2OBW7ByRFcu91dvboCpA9-TiJcz_cQBeC-uPy84gM=.b408488f-c8eb-4a5d-bedf-b61c118fc571@github.com>

On Tue, 23 Jan 2024 22:13:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implNote to Javadoc for toPattern().
>
> src/java.base/share/classes/java/text/MessageFormat.java line 1:
> 
>> 1: /*
> 
> For this file, please also bump the latter copyright year to 2024.

Will do.

> src/java.base/share/classes/java/text/MessageFormat.java line 585:
> 
>> 583:                     if (fmt instanceof DecimalFormat) {
>> 584:                         result.append(",number");
>> 585:                         subformatPattern = ((DecimalFormat)fmt).toPattern();
> 
> Could use pattern matching `instanceof` here and in the other instances, but I understand if you're trying to stay consistent with the existing code.

Agreed! Old habits :) I'll fix.

> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 56:
> 
>> 54: 
>> 55:     private static final int NUM_RANDOM_TEST_CASES = 1000;
>> 56:     private static final int MAX_FORMAT_NESTING = 3;
> 
> Can you add a comment defining `MAX_FORMAT_TESTING`, might not be immediately understood without further investigation

Will do.

> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 96:
> 
>> 94:     @ParameterizedTest
>> 95:     @MethodSource("testCases")
>> 96:     public void testRoundTrip(MessageFormat format1) {
> 
> Can we also include the original String pattern that created format1, to help with debugging. I find myself wondering what the original String was.
> 
> Since technically, the full round trip is _pattern string -> MessageFormat1 -> pattern string -> MessageFormat2_

I would have done that but it's not (easily) possible. The `MessageFormat`'s are created not from format strings, but by piecing together plain text and sub-`Format` objects manually. This was we are sure what we're dealing with.

Trying to create format strings with multiple levels of nesting from scratch is too complex for my brain due to all the levels of quoting required.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104293
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104138
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104181
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104467

From acobbs at openjdk.org  Tue Jan 23 23:15:32 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Jan 2024 23:15:32 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <SLbD3ysQl7WD43ouzjqKykKOCZLmSmH7ImiLau9aiaU=.c7570102-0fdc-421e-b0e1-a84005227324@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
 <SLbD3ysQl7WD43ouzjqKykKOCZLmSmH7ImiLau9aiaU=.c7570102-0fdc-421e-b0e1-a84005227324@github.com>
Message-ID: <2hZYIS2JiaimjmDS67wy3gje_rJxrFJi2SLveD2gUEc=.19b86355-b826-45e9-a692-73d257bcf5f1@github.com>

On Tue, 23 Jan 2024 23:00:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 556:
>> 
>>> 554:      * does not necessarily equal the previously applied pattern.
>>> 555:      *
>>> 556:      * @implNote The string returned by this method can be used to create
>> 
>> Hmm, I'm not sure about the current note, because its not true in all cases (for example, some unknown subclass of Format). Maybe @naotoj has thoughts?
>
> Yes, my comment to the CSR was to explain the default implementation as the `@implNote`. Making it explicit would be helpful to readers.

Yes my mistake, I'll change this to:

@implNote The implementation in {@link MessageFormat} returns a string
that can be used to create a new instance that is semantically equivalent
to this instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104922

From jlu at openjdk.org  Wed Jan 24 00:00:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jan 2024 00:00:26 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <dY2OBW7ByRFcu91dvboCpA9-TiJcz_cQBeC-uPy84gM=.b408488f-c8eb-4a5d-bedf-b61c118fc571@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
 <dY2OBW7ByRFcu91dvboCpA9-TiJcz_cQBeC-uPy84gM=.b408488f-c8eb-4a5d-bedf-b61c118fc571@github.com>
Message-ID: <ypl0q6bP1Z08buLxmYMRIMuDW6BVvfUunHI7N2zKVTA=.69e341e7-62ef-4055-8c73-ca92683c9460@github.com>

On Tue, 23 Jan 2024 23:12:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 96:
>> 
>>> 94:     @ParameterizedTest
>>> 95:     @MethodSource("testCases")
>>> 96:     public void testRoundTrip(MessageFormat format1) {
>> 
>> Can we also include the original String pattern that created format1, to help with debugging. I find myself wondering what the original String was.
>> 
>> Since technically, the full round trip is _pattern string -> MessageFormat1 -> pattern string -> MessageFormat2_
>
> I would have done that but it's not (easily) possible. The `MessageFormat`'s are created not from format strings, but by piecing together plain text and sub-`Format` objects manually. This was we are sure what we're dealing with.
> 
> Trying to create format strings with multiple levels of nesting from scratch is too complex for my brain due to all the levels of quoting required.

Right, should have noted that, definitely not worth to try and re-synthesize the original String pattern for each Format. If we're adding some additional concrete cases, its fine since those will clearly have the original String patterns there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464131694

From acobbs at openjdk.org  Wed Jan 24 00:21:44 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Jan 2024 00:21:44 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v4]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <qBTQyJF90w92AkWITW_HvJIVMBM8yRATdzTFtn9c_EQ=.6950da60-3e86-4e1f-b2d5-f7bf653e482e@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Archie Cobbs has updated the pull request incrementally with six additional commits since the last revision:

 - Add more test cases and more pattern string variety.
 - Make it easier to debug & show what the test is doing.
 - Add comment explaining what MAX_FORMAT_NESTING is for.
 - Clean up code a bit by using instanceof patterns.
 - Tweak @implNote to clarify only referring to MessageFormat class.
 - Update copyright year in MessageFormat.java.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/36d70b8a..58e8cc68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=02-03

  Stats: 94 lines in 2 files changed: 50 ins; 12 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From acobbs at openjdk.org  Wed Jan 24 00:21:46 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Jan 2024 00:21:46 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v3]
In-Reply-To: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
Message-ID: <5UccW0t33EHHwoxE3yDfK7ytOHD7KmRWKFFOsvYZ9Zo=.d7bdf3a2-e392-49e2-beb6-8f1ddd897689@github.com>

On Tue, 23 Jan 2024 22:15:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implNote to Javadoc for toPattern().
>
> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 90:
> 
>> 88:         // A few more test cases from the PR#17416 discussion
>> 89:         testRoundTrip(new MessageFormat("Test: {0,number,foo'{'#.00}"));
>> 90:         testRoundTrip(new MessageFormat("Test: {0,number,foo'}'#.00}"));
> 
> Can we add some more concrete test cases, for example, escaped quotes within a MessageFormat pattern (represented by doubled single quotes). 
> 
> Another funny case is something like a MessageFormat created by `"{0,number,' abc }'' ' 0.00}"` which becomes `"{0,number, abc '}'''  #0.00}"` after created from the value returned by toPattern() from the first MessageFormat. The Strings appear really different but format equivalently, it would be nice to have suspicious cases like these explicitly defined.

Sure thing - added in 58e8cc68f45.

> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 154:
> 
>> 152:     // Generate a "random" MessageFormat. We do this by creating a MessageFormat with "{0}" placeholders
>> 153:     // and then substituting in random DecimalFormat, DateFormat, and ChoiceFormat subformats. The goal here
>> 154:     // is to avoid using pattern strings to construct formats, because they're what we're trying to check.
> 
> Can you add a general example of a randomly generated MessageFormat in the comments, (I know they vary by quite a lot), but it would be hard for someone to piece if together without digging into the code. And unfortunately the current toString() of MessageFormat is not implemented, so although JUnit prints the MessageFormat out, it's just gibberish.

Added in 58e8cc68f45 as a test case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464143414
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464143622

From duke at openjdk.org  Wed Jan 24 00:32:36 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 24 Jan 2024 00:32:36 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes
Message-ID: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>

This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.

I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.

java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench


Before change


Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op


After change


Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op


We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.

-------------

Commit messages:
 - 8324573: HashMap::putAll should resize to sum of both map sizes

Changes: https://git.openjdk.org/jdk/pull/17544/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324573
  Stats: 39 lines in 2 files changed: 13 ins; 7 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544

PR: https://git.openjdk.org/jdk/pull/17544

From vromero at openjdk.org  Wed Jan 24 04:00:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 04:00:37 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
Message-ID: <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>

On Mon, 22 Jan 2024 18:42:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 60 commits:
> 
>  - Improve Javadoc of ExactConversionsSupport
>  - Merge branch 'master' into primitive-patterns
>  - Update ExactConversionsSupport Javadoc and JDK version
>  - Revert "Update copyright year, javadoc, JDK version"
>    
>    This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.
>  - Update copyright year, javadoc, JDK version
>  - Merge branch 'master' into primitive-patterns
>  - Merge branch 'master' into primitive-patterns
>  - Cleanup
>  - Merge branch 'master' into primitive-patterns
>  - Remove trailing spaces
>  - ... and 50 more: https://git.openjdk.org/jdk/compare/c9cacfb2...50cb9832

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 72:

> 70:     private static final Object SENTINEL = new Object();
> 71:     private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
> 72:     private static final boolean previewEnabled = true;

not sure about the use of this constant, do we really need it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464262036

From duke at openjdk.org  Wed Jan 24 04:58:35 2024
From: duke at openjdk.org (duke)
Date: Wed, 24 Jan 2024 04:58:35 GMT
Subject: Withdrawn: 8320712: Rewrite BadFactoryTest in pure Java
In-Reply-To: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
Message-ID: <kCzDnL35inrwHNnfd_QLU9bwDTJtDrOeGwsv0XsH_Y4=.4e193048-84cc-45bc-97e7-835d6fe3533e@github.com>

On Mon, 27 Nov 2023 17:44:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. 
> 
> Reviewers may notice the following changes:
> 
> - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java`
> - The main method has been replaced with a JUnit `@Test` method
> - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959`
> - The `@summary` tag was updated since the existing summary was slightly confusing
> - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager`
> - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see  #16585.
> 
> Verified by running:
> 
> 
> % make test TEST="test/jdk/javax/script/JDK_8196959"
>   [..]
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/javax/script/JDK_8196959               1     1     0     0   
> 
> 
> Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16830

From jpai at openjdk.org  Wed Jan 24 05:06:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Jan 2024 05:06:47 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java
In-Reply-To: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
Message-ID: <ERcmL3Yz8FbA16Hkfw7RUOcFnHZzdMoznHI4AoMRaz0=.bfe22528-7937-4e86-a306-c5074e6c7fad@github.com>

On Mon, 27 Nov 2023 17:44:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. 
> 
> Reviewers may notice the following changes:
> 
> - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java`
> - The main method has been replaced with a JUnit `@Test` method
> - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959`
> - The `@summary` tag was updated since the existing summary was slightly confusing
> - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager`
> - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see  #16585.
> 
> Verified by running:
> 
> 
> % make test TEST="test/jdk/javax/script/JDK_8196959"
>   [..]
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/javax/script/JDK_8196959               1     1     0     0   
> 
> 
> Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection.

Hello Eirik, what's being proposed here looks good to me. It's good that this is being migrated from a shell based test to a java based test. So if you are interested in pursuing this further, please reopen the PR.

The only part that is unclear to me is the use of `@library /javax/script/JDK_8196959`. Does the test fail if that isn't added?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16830#issuecomment-1907384336

From dholmes at openjdk.org  Wed Jan 24 06:14:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Jan 2024 06:14:27 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
Message-ID: <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>

On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use null to denote boot class loader as delegation parent

The actual changes to load JVMCI via the platform loader seem fine.

I'm still puzzled by the need to do this as any non-delegating classloader would have allowed this even if JVMCI were loaded by the bootloader. And I don't understand how your test is working as it is using a delegating classloader.

test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 54:

> 52: 
> 53:         ClassLoader pcl = ClassLoader.getPlatformClassLoader();
> 54:         URLClassLoader ucl = new URLClassLoader(cp, null);

I am missing something here, a `URLClassLoader` first delegates to its parent before searching its URLs, so how does this not find the platform loader versions of the JVMCI classes?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17520#pullrequestreview-1840477028
PR Review Comment: https://git.openjdk.org/jdk/pull/17520#discussion_r1464348710

From dholmes at openjdk.org  Wed Jan 24 06:30:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Jan 2024 06:30:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
Message-ID: <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>

On Tue, 23 Jan 2024 22:46:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 56:
>> 
>>> 54:      */
>>> 55:     @IntrinsicCandidate
>>> 56:     public static boolean isCompileConstant(boolean expr) {
>> 
>> Here and in other places: probably not `expr`, but just `val` or something?
>
> I think of this as an expression that is always evaluated to the same value. The value itself is not interesting, it is the set of values that this expression can take that we are talking about.

This seems really weird to me for Java code. The method doesn't get the original "expression" it only gets the value of that expression after it has been evaluated. Is there some kind of weird "magic" happening here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464361310

From eirbjo at openjdk.org  Wed Jan 24 06:50:36 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 24 Jan 2024 06:50:36 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
Message-ID: <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>

> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. 
> 
> Reviewers may notice the following changes:
> 
> - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java`
> - The main method has been replaced with a JUnit `@Test` method
> - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959`
> - The `@summary` tag was updated since the existing summary was slightly confusing
> - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager`
> - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see  #16585.
> 
> Verified by running:
> 
> 
> % make test TEST="test/jdk/javax/script/JDK_8196959"
>   [..]
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/javax/script/JDK_8196959               1     1     0     0   
> 
> 
> Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection.

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Remove the @library tag, the META-INF service definition file is already on the classpath
 - Merge branch 'master' into badfactory-java-rewritte
 - Add the Java rewrite issue to the @bug list
 - Merge branch 'master' into badfactory-java-rewritte
   
   # Conflicts:
   #	test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh
 - Move jtreg tags from before to after imports
 - Merge branch 'master' into badfactory-java-rewritte
 - Update the @summary to describe the purpose of the test, not the BadFactory
 - Add comment describing the initialization of ScriptEngineManager
 - Implement BadFactoryTest in pure Java

-------------

Changes: https://git.openjdk.org/jdk/pull/16830/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16830&range=01
  Stats: 86 lines in 2 files changed: 24 ins; 60 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16830/head:pull/16830

PR: https://git.openjdk.org/jdk/pull/16830

From eirbjo at openjdk.org  Wed Jan 24 06:53:27 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 24 Jan 2024 06:53:27 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java
In-Reply-To: <ERcmL3Yz8FbA16Hkfw7RUOcFnHZzdMoznHI4AoMRaz0=.bfe22528-7937-4e86-a306-c5074e6c7fad@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <ERcmL3Yz8FbA16Hkfw7RUOcFnHZzdMoznHI4AoMRaz0=.bfe22528-7937-4e86-a306-c5074e6c7fad@github.com>
Message-ID: <aUHyqsidK8gQ8AGl1BmOpYgQ5rPtcRRgC-0ZnmV_Lhs=.df8246ee-ff18-4fd3-84dd-67c84f690588@github.com>

On Wed, 24 Jan 2024 05:03:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The only part that is unclear to me is the use of `@library /javax/script/JDK_8196959`. Does the test fail if that isn't added?

Thanks! I must have thought this was required to put the service definition file on the classpath. But it isn't.

I have removed the `@library` tag and also merged with a more recent master.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16830#issuecomment-1907474466

From jpai at openjdk.org  Wed Jan 24 07:10:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Jan 2024 07:10:31 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
Message-ID: <XUu4HrzCChqMUMyJ1U_XRxORNKz57lQorRGEX_sAwXg=.b9bc4b8e-63d5-43b3-a90d-5ae8d36d6869@github.com>

On Wed, 24 Jan 2024 06:50:36 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. 
>> 
>> Reviewers may notice the following changes:
>> 
>> - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java`
>> - The main method has been replaced with a JUnit `@Test` method
>> - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959`
>> - The `@summary` tag was updated since the existing summary was slightly confusing
>> - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager`
>> - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see  #16585.
>> 
>> Verified by running:
>> 
>> 
>> % make test TEST="test/jdk/javax/script/JDK_8196959"
>>   [..]
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/javax/script/JDK_8196959               1     1     0     0   
>> 
>> 
>> Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Remove the @library tag, the META-INF service definition file is already on the classpath
>  - Merge branch 'master' into badfactory-java-rewritte
>  - Add the Java rewrite issue to the @bug list
>  - Merge branch 'master' into badfactory-java-rewritte
>    
>    # Conflicts:
>    #	test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh
>  - Move jtreg tags from before to after imports
>  - Merge branch 'master' into badfactory-java-rewritte
>  - Update the @summary to describe the purpose of the test, not the BadFactory
>  - Add comment describing the initialization of ScriptEngineManager
>  - Implement BadFactoryTest in pure Java

Thank you for the update. This test-only change looks OK to me.

Hello Sundar @sundararajana, given your past work on this test, do you have any thoughts on this change?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16830#pullrequestreview-1840572685

From qamai at openjdk.org  Wed Jan 24 07:17:27 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 24 Jan 2024 07:17:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
 <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>
Message-ID: <9iDFu8I4w_i1Uso5q7oEi0Le1JvgDNgNyuSZlmKQiuE=.5739d448-fc73-4bcf-bec8-26b3a1b75d21@github.com>

On Wed, 24 Jan 2024 06:27:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think of this as an expression that is always evaluated to the same value. The value itself is not interesting, it is the set of values that this expression can take that we are talking about.
>
> This seems really weird to me for Java code. The method doesn't get the original "expression" it only gets the value of that expression after it has been evaluated. Is there some kind of weird "magic" happening here?

@dholmes-ora Indeed it's a compiler magic, albeit not really weird. While the method execution only receives the evaluated value of `expr`, the method compilation has the expression in its original form. As a result, it can determine the result based on this information.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464415357

From hgreule at openjdk.org  Wed Jan 24 08:38:27 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 24 Jan 2024 08:38:27 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <4dgi9uYg4huoW1xx60XLr5aitOJfhgIKFFjvO8RiPDs=.136f0598-5da6-4fc5-a90a-c1af49e7d7ee@github.com>

On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao <duke at openjdk.org> wrote:

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.

The current benchmark and the change don't really cover the case where many keys exist in *both* maps. Could you add a benchmark for that? Also `int s = size() + m.size();` can overflow now, leading to different behavior. It might make sense to just cap the value?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1907639418

From dnsimon at openjdk.org  Wed Jan 24 08:48:29 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Jan 2024 08:48:29 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
Message-ID: <_FCKvxLQxWZCfs-1Rxjr3qtcwMomMA368p_-6aJeTPQ=.db4d0b6f-205b-4127-b040-740e476e0919@github.com>

On Wed, 24 Jan 2024 06:07:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use null to denote boot class loader as delegation parent
>
> test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 54:
> 
>> 52: 
>> 53:         ClassLoader pcl = ClassLoader.getPlatformClassLoader();
>> 54:         URLClassLoader ucl = new URLClassLoader(cp, null);
> 
> I am missing something here, a `URLClassLoader` first delegates to its parent before searching its URLs, so how does this not find the platform loader versions of the JVMCI classes?

With `new URLClassLoader(cp, null)`, the URL loader delegates directly to the boot loader, by-passing the platform loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17520#discussion_r1464529290

From dnsimon at openjdk.org  Wed Jan 24 08:58:26 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Jan 2024 08:58:26 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
Message-ID: <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>

On Wed, 24 Jan 2024 06:11:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm still puzzled by the need to do this as any non-delegating classloader would have allowed this even if JVMCI were loaded by the bootloader.

As far as I understand, even a non-delegating classloader cannot redefine a class loaded by the boot loader. I modified the test to show this and get:

java.lang.LinkageError: loader LoadAlternativeJVMCI$1 @4a1f4d08 attempted duplicate class definition for jdk.vm.ci.meta.ResolvedJavaType. (jdk.vm.ci.meta.ResolvedJavaType is in unnamed module of loader LoadAlternativeJVMCI$1 @4a1f4d08, parent loader 'bootstrap')
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1023)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
	at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
	at LoadAlternativeJVMCI$1.loadClass(LoadAlternativeJVMCI.java:61)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
	at LoadAlternativeJVMCI.main(LoadAlternativeJVMCI.java:77)
	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:1575)


Test modification:

diff --git a/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java b/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
index dd63867e7c2..28a6fedca38 100644
--- a/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
+++ b/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
@@ -51,7 +51,14 @@ public static void main(String[] args) throws Exception {
         }

         ClassLoader pcl = ClassLoader.getPlatformClassLoader();
-        URLClassLoader ucl = new URLClassLoader(cp, null);
+        URLClassLoader ucl = new URLClassLoader(cp, null) {
+            protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
+                if (!name.startsWith("jdk.vm.ci")) {
+                    return super.loadClass(name, resolve);
+                }
+                return findClass(name);
+            }
+        };

         String[] names = {
             "jdk.vm.ci.meta.ResolvedJavaType",

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1907671987

From shade at openjdk.org  Wed Jan 24 08:58:30 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 08:58:30 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <vgDkJF9ZKMLwCab_YQZEXs8VHrgwNbyhVOVC1bJ0W-E=.7de2dc69-d2fb-44ab-a38f-1ba2a893d4ef@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <vgDkJF9ZKMLwCab_YQZEXs8VHrgwNbyhVOVC1bJ0W-E=.7de2dc69-d2fb-44ab-a38f-1ba2a893d4ef@github.com>
Message-ID: <trhTF489ibsuKq7IeDPreq5bt83BFfNOASZlGgvoWkM=.a0740c85-c1bc-4908-a814-00a9175b7e42@github.com>

On Tue, 23 Jan 2024 22:41:44 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 119:
>> 
>>> 117:      * @see #isCompileConstant(boolean)
>>> 118:      */
>>> 119:     @IntrinsicCandidate
>> 
>> Note how the Java entry for MH intrinsic we have replaced had `@Hidden`. These methods should have `@Hidden` too then? Probably applies to other entries too.
>
> I don't understand why this needs to be `@Hidden`, the javadoc says that a function annotated with `@Hidden` is omitted from the stacktraces. This function does not call anything so what is the point of hiding it?

I suspect there is a code that counts stack traces somewhere that relies on it in MH parts. There is no harm for doing `@Hidden` here, I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464541674

From shade at openjdk.org  Wed Jan 24 09:06:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 09:06:29 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <81tjQoutCZRej3wZAnPDJIq31hz7D7tbiJLWyWpXXv0=.5786bc11-7aa2-4290-a1d5-37c82452ed41@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <LJ1FdhkTa6IjZDirNhY5J7C08VSzuQjbYW5srsBanmA=.ce805ea5-3260-4c74-939b-06656ff6493f@github.com>
 <81tjQoutCZRej3wZAnPDJIq31hz7D7tbiJLWyWpXXv0=.5786bc11-7aa2-4290-a1d5-37c82452ed41@github.com>
Message-ID: <dDX6qb02rzMqaz7OuGq-YBA2xOUKYSSVi5fIVdOvNfE=.6436d8d6-0668-4ca8-91df-3db68707cd82@github.com>

On Tue, 23 Jan 2024 22:49:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 32:
>> 
>>> 30:  * Just-in-time-compiler-related queries
>>> 31:  */
>>> 32: public class JitCompiler {
>> 
>> An alternative name and location is `jdk.internal.vm.ConstantSupport` with initial class doc:
>> 
>> Defines methods to test if a value has been evaluated to a compile-time constant value by the HotSpot VM.
>
> That sounds like a better name for the class, although I think `jdk.internal.misc` is more suitable than `jdk.internal.vm`. Do you have any preference? Thanks.

+1 to `ConstantSupport`. I think `jdk.internal.vm` is a proper place for it. There is adjacent `jdk.internal.vm.vector.VectorSupport`, and whole `jdk.internal.vm.annotations` package is there too.

`jdk.internal.misc` sounds like a place for utility classes. `Unsafe` is a historical exception, I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464551793

From duke at openjdk.org  Wed Jan 24 09:50:26 2024
From: duke at openjdk.org (Paul Woegerer)
Date: Wed, 24 Jan 2024 09:50:26 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader
In-Reply-To: <Sm2rX0wf19A8q0rRdskZN17JmY9WyGmu-DKBLWtkbPk=.aa86c45e-91aa-4ad9-b729-585ab201ddf5@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <Sm2rX0wf19A8q0rRdskZN17JmY9WyGmu-DKBLWtkbPk=.aa86c45e-91aa-4ad9-b729-585ab201ddf5@github.com>
Message-ID: <N4mJpIKxzCJb4phAVNUn_13XrjpCaPRzDMe5cFpMM2I=.f3dd930b-6be3-41fd-bf78-38477cae93a1@github.com>

On Tue, 23 Jan 2024 17:00:20 GMT, xxDark <duke at openjdk.org> wrote:

> There is zero reason to do this. Passing `null` as parent class loader would suffice as boot loader just uses `findBootstrapClassOrNull` in `JavaLangAccess` either way.

Right, using `null` does the same thing. In the final version will use that instead of accessing private field `jdk.internal.loader.ClassLoaders#BOOT_LOADER`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1907772059

From mbaesken at openjdk.org  Wed Jan 24 10:12:33 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 24 Jan 2024 10:12:33 GMT
Subject: RFR: JDK-8324598: use mem_unit when working with sysinfo memory and
 swap related information
Message-ID: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>

According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
"In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."

This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.

-------------

Commit messages:
 - JDK-8324598

Changes: https://git.openjdk.org/jdk/pull/17550/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324598
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17550/head:pull/17550

PR: https://git.openjdk.org/jdk/pull/17550

From eirbjo at openjdk.org  Wed Jan 24 10:28:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 24 Jan 2024 10:28:46 GMT
Subject: RFR: 8321396: Retire
 test/jdk/java/util/zip/NoExtensionSignature.java [v2]
In-Reply-To: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
References: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
Message-ID: <Lbuyw7UELVk8swsl_pdKpV0iikxN7OX5ia7VigbtxKk=.25dc3e9e-54c4-422b-ac89-293f3a999c3d@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, see #12959. That test is more complete, includes more documentation and uses a programmatically generated test vector.
> 
> 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.

Eirik Bj?rsn?s has updated the pull request with a new target base 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 retire-no-extension-signature
 - 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:
  - all: https://git.openjdk.org/jdk/pull/16975/files
  - new: https://git.openjdk.org/jdk/pull/16975/files/854060a4..bd9e8738

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16975&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16975&range=00-01

  Stats: 155679 lines in 2876 files changed: 86094 ins; 58372 del; 11213 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 jlahoda at openjdk.org  Wed Jan 24 10:29:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 Jan 2024 10:29:35 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
 <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
Message-ID: <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>

On Wed, 24 Jan 2024 03:47:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Improve Javadoc of ExactConversionsSupport
>>  - Merge branch 'master' into primitive-patterns
>>  - Update ExactConversionsSupport Javadoc and JDK version
>>  - Revert "Update copyright year, javadoc, JDK version"
>>    
>>    This reverts commit 676af9de90d946f64f34762a6df94dbd91bce41b.
>>  - Update copyright year, javadoc, JDK version
>>  - Merge branch 'master' into primitive-patterns
>>  - Merge branch 'master' into primitive-patterns
>>  - Cleanup
>>  - Merge branch 'master' into primitive-patterns
>>  - Remove trailing spaces
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/c9cacfb2...50cb9832
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 72:
> 
>> 70:     private static final Object SENTINEL = new Object();
>> 71:     private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
>> 72:     private static final boolean previewEnabled = true;
> 
> not sure about the use of this constant, do we really need it?

Uh, I think this is a good catch.

I am not completely sure what the policy is, but here we are enhancing a non-preview method with some preview-based behavior. I would feel better if the method would refuse to work in the preview way when preview is not enabled. I.e. my opinion is that this should either be initialized to `jdk.internal.misc.PreviewFeatures.isEnabled()`, or `jdk.internal.misc.PreviewFeatures.ensureEnabled()` should be used appropriately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464693259

From qamai at openjdk.org  Wed Jan 24 10:33:05 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 24 Jan 2024 10:33:05 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  address reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17527/files
  - new: https://git.openjdk.org/jdk/pull/17527/files/3ecb2c66..b4445e2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=04-05

  Stats: 36 lines in 4 files changed: 10 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From qamai at openjdk.org  Wed Jan 24 10:40:27 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 24 Jan 2024 10:40:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <dDX6qb02rzMqaz7OuGq-YBA2xOUKYSSVi5fIVdOvNfE=.6436d8d6-0668-4ca8-91df-3db68707cd82@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <LJ1FdhkTa6IjZDirNhY5J7C08VSzuQjbYW5srsBanmA=.ce805ea5-3260-4c74-939b-06656ff6493f@github.com>
 <81tjQoutCZRej3wZAnPDJIq31hz7D7tbiJLWyWpXXv0=.5786bc11-7aa2-4290-a1d5-37c82452ed41@github.com>
 <dDX6qb02rzMqaz7OuGq-YBA2xOUKYSSVi5fIVdOvNfE=.6436d8d6-0668-4ca8-91df-3db68707cd82@github.com>
Message-ID: <jiUMtdODgoDmO6Xn9RgljGcF3ppvfAB27fke65aDSj8=.acc3e1bb-aa36-4efd-b63b-415d5d81c488@github.com>

On Wed, 24 Jan 2024 09:03:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> That sounds like a better name for the class, although I think `jdk.internal.misc` is more suitable than `jdk.internal.vm`. Do you have any preference? Thanks.
>
> +1 to `ConstantSupport`. I think `jdk.internal.vm` is a proper place for it. There is adjacent `jdk.internal.vm.vector.VectorSupport`, and whole `jdk.internal.vm.annotations` package is there too.
> 
> `jdk.internal.misc` sounds like a place for utility classes. `Unsafe` is a historical exception, I think.

I see, my main premise is that it is somewhat similar to `Unsafe` which turns out to be an exception :) Thanks a lot for your suggestions, I have updated the PR, also added `@Hidden` back.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1464707689

From alanb at openjdk.org  Wed Jan 24 10:49:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Jan 2024 10:49:28 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
Message-ID: <nd1j3UmYdWOhAlbVaoxZc7Nv2pYvFPwrHxrMddJAOeQ=.c19ca581-7579-433e-b862-d7f10ccb2c84@github.com>

On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use null to denote boot class loader as delegation parent

test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 50:

> 48:                 e = e + File.separator;
> 49:             }
> 50:             cp[i] = new URI("file:" + e).toURL();

This should be `cp[I] = file.toURI().toURL()` as a file path needs encoding to be URI path component.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17520#discussion_r1464719091

From dholmes at openjdk.org  Wed Jan 24 11:49:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Jan 2024 11:49:26 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <_FCKvxLQxWZCfs-1Rxjr3qtcwMomMA368p_-6aJeTPQ=.db4d0b6f-205b-4127-b040-740e476e0919@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
 <_FCKvxLQxWZCfs-1Rxjr3qtcwMomMA368p_-6aJeTPQ=.db4d0b6f-205b-4127-b040-740e476e0919@github.com>
Message-ID: <7EhdI22NKmX21ef4jKqIsDLLjiMPUdt1nJvSHbo0i6g=.55e87451-c50f-417b-8b90-c3dff31e1d35@github.com>

On Wed, 24 Jan 2024 08:46:08 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 54:
>> 
>>> 52: 
>>> 53:         ClassLoader pcl = ClassLoader.getPlatformClassLoader();
>>> 54:         URLClassLoader ucl = new URLClassLoader(cp, null);
>> 
>> I am missing something here, a `URLClassLoader` first delegates to its parent before searching its URLs, so how does this not find the platform loader versions of the JVMCI classes?
>
> With `new URLClassLoader(cp, null)`, the URL loader delegates directly to the boot loader, by-passing the platform loader.

<face-palm>

Thanks Doug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17520#discussion_r1464798827

From abimpoudis at openjdk.org  Wed Jan 24 11:53:52 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 11:53:52 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@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:

  Set previewEnabled properly in SwitchBootstraps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/50cb9832..663c7a54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=40-41

  Stats: 3 lines in 1 file changed: 1 ins; 1 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 abimpoudis at openjdk.org  Wed Jan 24 11:53:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 11:53:54 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v41]
In-Reply-To: <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
 <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
 <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>
Message-ID: <BHwX3HCGZZiil_8ZBdwP0gcd5zJySeF_I4US6t245qE=.8c39683f-24cc-4d55-a2f8-a65c045984a1@github.com>

On Wed, 24 Jan 2024 10:26:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 72:
>> 
>>> 70:     private static final Object SENTINEL = new Object();
>>> 71:     private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
>>> 72:     private static final boolean previewEnabled = true;
>> 
>> not sure about the use of this constant, do we really need it?
>
> Uh, I think this is a good catch.
> 
> I am not completely sure what the policy is, but here we are enhancing a non-preview method with some preview-based behavior. I would feel better if the method would refuse to work in the preview way when preview is not enabled. I.e. my opinion is that this should either be initialized to `jdk.internal.misc.PreviewFeatures.isEnabled()`, or `jdk.internal.misc.PreviewFeatures.ensureEnabled()` should be used appropriately.

Used the `jdk.internal.misc.PreviewFeatures.isEnabled()` and remove an erroneous check in `typeSwitch`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464801847

From goetz at openjdk.org  Wed Jan 24 11:58:36 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 24 Jan 2024 11:58:36 GMT
Subject: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9
 aarch64
In-Reply-To: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
References: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
Message-ID: <Mu587jxeT7O7jEgU685cs-rFXK0Jg8f9OxJhwSGyEuc=.4b90636b-7cb2-44dc-b329-46f576752da3@github.com>

On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this to fix this issue in 22. We see it failing there in our CI.

Passed SAP nighlyt testing with jdk22 and jdk22u.

-------------

PR Comment: https://git.openjdk.org/jdk22/pull/95#issuecomment-1907981934

From dholmes at openjdk.org  Wed Jan 24 11:59:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Jan 2024 11:59:29 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
Message-ID: <Us2jRppsw6e9fqRF-1Bq2G2S5sR1deX2LLx4KW1l9lk=.3cee3c0e-4bc9-4cb5-9f0a-1f435dae6ff8@github.com>

On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use null to denote boot class loader as delegation parent

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17520#pullrequestreview-1841205744

From dholmes at openjdk.org  Wed Jan 24 11:59:31 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Jan 2024 11:59:31 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
 <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
Message-ID: <MHpQaiNS1FTIAQ02afU-DFWKxl4BcwWioPtjyMq7dDM=.771a3b57-9355-463b-ba77-715532571586@github.com>

On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> As far as I understand, even a non-delegating classloader cannot redefine a class loaded by the boot loader. I modified the test to show this and get:
> 
> ```
> java.lang.LinkageError: loader LoadAlternativeJVMCI$1 @4a1f4d08 attempted duplicate class definition for jdk.vm.ci.meta.ResolvedJavaType. (jdk.vm.ci.meta.ResolvedJavaType is in unnamed module of loader LoadAlternativeJVMCI$1 @4a1f4d08, parent loader 'bootstrap')
> 	at java.base/java.lang.ClassLoader.defineClass1(Native Method)

Interesting. I'm not sure why that should be happening in this case. I can imagine a potential split-package issue with the bootloader that doesn't happen with the platform loader. I will look into it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1907983591

From mcimadamore at openjdk.org  Wed Jan 24 12:17:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:17:38 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <_hlWjNWAiPgvNTpwVWsBKURLCwySlIt5GoWiWKTJLRs=.3f069a48-2a82-408a-ba40-84d2b75b8ed3@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 34:

> 32:  * may be used, for example, by Java compiler implementations to implement
> 33:  * checks for {@code instanceof} and pattern matching runtime implementations.
> 34:  * Unconditionally exact testing conversions do not require a corresponding

"... do not require a corresponding action at runtime" ... and, for this reason, method corresponding to these conversions are omitted here

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 37:

> 35:  * action at run time.
> 36:  * <p>
> 37:  * The run time conversion checks examine whether loss of information would

You provide examples for runtime conversions - it would be useful, before this para, to also have examples of an inexact conversion, an exact conversion and an unconditionally exact conversion (before diving into the details of how the runtime check is performed for floating points).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464828250
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464826696

From mcimadamore at openjdk.org  Wed Jan 24 12:25:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:25:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5046:

> 5044: 
> 5045:         if (target.isPrimitive()) {
> 5046:             return (source.isReference() && isSubtype(source, target)) ||

I'm a bit confused here - in here we have:
* `target.isPrimitive()`
* `source.isReference()`

So, isn't it the case that `isSubtype(source, target)` is always false?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1924:

> 1922:     }
> 1923:     // where
> 1924:     static final Set<TypeTag> nonIntegralPrimitiveTypes = Set.of(

This feels like a method on TypeTag?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464835145
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464836721

From duke at openjdk.org  Wed Jan 24 12:19:27 2024
From: duke at openjdk.org (xxDark)
Date: Wed, 24 Jan 2024 12:19:27 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
 <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
Message-ID: <IFyEWdA9yqoH10xLa4VryRW3rBWl5_mfFSBV2uup9jQ=.5efe865f-365c-44f7-82d9-04e9ec1020ac@github.com>

On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > I'm still puzzled by the need to do this as any non-delegating classloader would have allowed this even if JVMCI were loaded by the bootloader.
> 
> As far as I understand, even a non-delegating classloader cannot redefine a class loaded by the boot loader. I modified the test to show this and get:
> 
> ```
> java.lang.LinkageError: loader LoadAlternativeJVMCI$1 @4a1f4d08 attempted duplicate class definition for jdk.vm.ci.meta.ResolvedJavaType. (jdk.vm.ci.meta.ResolvedJavaType is in unnamed module of loader LoadAlternativeJVMCI$1 @4a1f4d08, parent loader 'bootstrap')
> 	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1023)
> 	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> 	at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
> 	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
> 	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
> 	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
> 	at LoadAlternativeJVMCI$1.loadClass(LoadAlternativeJVMCI.java:61)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
> 	at LoadAlternativeJVMCI.main(LoadAlternativeJVMCI.java:77)
> 	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:1575)
> ```
> 
> Test modification:
> 
> ```
> diff --git a/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java b/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
> index dd63867e7c2..28a6fedca38 100644
> --- a/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
> +++ b/test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java
> @@ -51,7 +51,14 @@ public static void main(String[] args) throws Exception {
>          }
> 
>          ClassLoader pcl = ClassLoader.getPlatformClassLoader();
> -        URLClassLoader ucl = new URLClassLoader(cp, null);
> +        URLClassLoader ucl = new URLClassLoader(cp, null) {
> +            protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
> +                if (!name.startsWith("jdk.vm.ci")) {
> +                    return super.loadClass(name, resolve);
> +                }
> +                return findClass(name);
> +            }
> +        };
> 
>          String[] names = {
>              "jdk.vm.ci.meta.ResolvedJavaType",
> ```

It can. You need to check if class is already loaded by trying `findLoadedClass` first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908013421

From mcimadamore at openjdk.org  Wed Jan 24 12:34:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:34:35 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <CviCTLebzieKrzLbh8QJKnL0QjSYeMdH_CdYjID1IvE=.54868a77-acb2-471f-b173-d1caae1c2ff4@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4147:

> 4145:         }
> 4146:         if (clazztype.isPrimitive()) {
> 4147:             preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);

So, if I have a primitive instanceof, I get two preview warnings, one for the expression, and one for the pattern type? Shouldn't one be enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464846948

From mcimadamore at openjdk.org  Wed Jan 24 12:43:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 12:43:36 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v42]
In-Reply-To: <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
Message-ID: <7L1Al1Y3JbKk3Xw624IOvM1ESmoRmmzkHRPbs-Wy4J0=.f9d0acee-0f06-41ea-889e-a035208d38aa@github.com>

On Wed, 24 Jan 2024 11:53:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Set previewEnabled properly in SwitchBootstraps

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2962:

> 2960:      * More rewritings:
> 2961:      *
> 2962:      * - If the `instanceof` check is unconditionally exact rewrite to true.

Note: the same effect can be obtained, w/o rewriting (and perhaps more simply) by detecting the case of an unconditionally exact "instanceof" test, and giving the instanceof expression a constant boolean type (with value "true"). This can be done in Attr. Then, `Gen` will shortcircuit the expression, as required.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1464857684

From viktor.klang at oracle.com  Wed Jan 24 13:34:11 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 24 Jan 2024 13:34:11 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>

Presuming that you mean mutating the Gatherer such that its behavior isn't stable, the difference (at least to me) is that creating such a mutable Gatherer would violate the specification of Gatherer: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Tuesday, 23 January 2024 21:04
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 10:06:27 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.
But I presume this also requires to have a `int characteristics()`-method on the Gatherer interfacewhich means that users who are not using the factory methods will have full possibility of not only returning the flags, but returning any int.

The current implementation suffers the same kind of issue, it's easy to write a mutable Gatherer and change the functions after creation, worst, right in the middle of a call to stream.gather(...).

Perhaps the Gatherer interface should be sealed ? We did not have that option during the 1.8 timeframe, when the Collector API was created.



The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.
I can see where you're coming from here, but to me, adding API surface needs to pull its weight.
In this case I wasn't convinced that it did, hence we're having this conversation. \uD83D\uDE42

Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated


________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.





Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.


public static int toOpFlags(int characteristics) {
return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---

public class GathererFlag {
// cut and paste from StreamOpFlag
  /**
   * The bit pattern for setting/injecting a flag.
   */
private static final int SET_BITS = 0b01;

/**
   * The bit pattern for clearing a flag.
   */
private static final int CLEAR_BITS = 0b10;

/**
   * The bit pattern for preserving a flag.
   */
private static final int PRESERVE_BITS = 0b11;


private static int position(int opFlagSet) {
return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
  }

private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
private static final int STATELESS_POSITION = 14;
private static final int PARELLIZABLE_POSITION = 15;

public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

// no GREEDY here
private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

private static final int STREAM_OP_MASK =
      ((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

public static String toString(int characteristics) {
return Stream.of(characteristics)
        .<String>mapMulti((f, consumer) -> {
if ((f & PARELLIZABLE) == PARELLIZABLE) {
consumer.accept("PARELLIZABLE");
          }
if ((f & STATELESS) == STATELESS) {
consumer.accept("STATELESS");
          }
if ((f & GREEDY) == GREEDY) {
consumer.accept("GREEDY");
          }
if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
consumer.accept("KEEP_DISTINCT");
          }
if ((f & KEEP_SORTED) == KEEP_SORTED) {
consumer.accept("KEEP_SORTED");
          }
if ((f & KEEP_SIZED) == KEEP_SIZED) {
consumer.accept("KEEP_SIZED");
          }
        })
        .collect(Collectors.joining(", "));
  }

public static int toOpFlags(int characteristics) {
return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240124/822d0550/attachment-0001.htm>

From lucy at openjdk.org  Wed Jan 24 13:18:32 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 24 Jan 2024 13:18:32 GMT
Subject: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9
 aarch64
In-Reply-To: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
References: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
Message-ID: <jREYbwB-y3Qr58VewMrdnThVuAn3PvuaK9qQtz4ZJDg=.42c5a9a9-e9cb-4d30-a082-7f2fe347b954@github.com>

On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this to fix this issue in 22. We see it failing there in our CI.

Looks good.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/95#pullrequestreview-1841351221

From jlaskey at openjdk.org  Wed Jan 24 13:23:49 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 Jan 2024 13:23:49 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v9]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <4wvO-Q9bbbg4kFD1u3yJSt8aazvW5BP9eLp4epde4AU=.6a27769a-7be9-49ce-af41-d85ed5232c55@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update String.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/eba05c2d..8fd58b55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=07-08

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From viktor.klang at oracle.com  Wed Jan 24 13:45:15 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 24 Jan 2024 13:45:15 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766F7C85A1CD53DFEBA7EDBFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <374502435.105761644.1705591034377.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>

As a (related) side-note, the ability to implement the interface directly has a significant benefit to being able to have tighter control on efficiency/performance as well as behavior under composition, here are some examples: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang <viktor.klang at oracle.com>
Sent: Wednesday, 24 January 2024 14:34
To: forax at univ-mlv.fr <forax at univ-mlv.fr>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: Re: Gatherer: spliterator characteristics are not propagated

Presuming that you mean mutating the Gatherer such that its behavior isn't stable, the difference (at least to me) is that creating such a mutable Gatherer would violate the specification of Gatherer: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Tuesday, 23 January 2024 21:04
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 10:06:27 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.
But I presume this also requires to have a `int characteristics()`-method on the Gatherer interfacewhich means that users who are not using the factory methods will have full possibility of not only returning the flags, but returning any int.

The current implementation suffers the same kind of issue, it's easy to write a mutable Gatherer and change the functions after creation, worst, right in the middle of a call to stream.gather(...).

Perhaps the Gatherer interface should be sealed ? We did not have that option during the 1.8 timeframe, when the Collector API was created.



The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.
I can see where you're coming from here, but to me, adding API surface needs to pull its weight.
In this case I wasn't convinced that it did, hence we're having this conversation. \uD83D\uDE42

Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated


________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.





Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.


public static int toOpFlags(int characteristics) {
return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---

public class GathererFlag {
// cut and paste from StreamOpFlag
  /**
   * The bit pattern for setting/injecting a flag.
   */
private static final int SET_BITS = 0b01;

/**
   * The bit pattern for clearing a flag.
   */
private static final int CLEAR_BITS = 0b10;

/**
   * The bit pattern for preserving a flag.
   */
private static final int PRESERVE_BITS = 0b11;


private static int position(int opFlagSet) {
return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
  }

private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
private static final int STATELESS_POSITION = 14;
private static final int PARELLIZABLE_POSITION = 15;

public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

// no GREEDY here
private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

private static final int STREAM_OP_MASK =
      ((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

public static String toString(int characteristics) {
return Stream.of(characteristics)
        .<String>mapMulti((f, consumer) -> {
if ((f & PARELLIZABLE) == PARELLIZABLE) {
consumer.accept("PARELLIZABLE");
          }
if ((f & STATELESS) == STATELESS) {
consumer.accept("STATELESS");
          }
if ((f & GREEDY) == GREEDY) {
consumer.accept("GREEDY");
          }
if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
consumer.accept("KEEP_DISTINCT");
          }
if ((f & KEEP_SORTED) == KEEP_SORTED) {
consumer.accept("KEEP_SORTED");
          }
if ((f & KEEP_SIZED) == KEEP_SIZED) {
consumer.accept("KEEP_SIZED");
          }
        })
        .collect(Collectors.joining(", "));
  }

public static int toOpFlags(int characteristics) {
return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240124/ed7b8cc8/attachment-0001.htm>

From dnsimon at openjdk.org  Wed Jan 24 13:50:28 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Jan 2024 13:50:28 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <IFyEWdA9yqoH10xLa4VryRW3rBWl5_mfFSBV2uup9jQ=.5efe865f-365c-44f7-82d9-04e9ec1020ac@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
 <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
 <IFyEWdA9yqoH10xLa4VryRW3rBWl5_mfFSBV2uup9jQ=.5efe865f-365c-44f7-82d9-04e9ec1020ac@github.com>
Message-ID: <5jXTeDsMH-p2MOufqzCMIdfk2QIjwbQoXOwrblDDJVQ=.80af7dfe-d3ae-4dd9-8cda-f5e55ed6474d@github.com>

On Wed, 24 Jan 2024 12:16:44 GMT, xxDark <duke at openjdk.org> wrote:

> You need to check if class is already loaded by trying findLoadedClass first.

You're right. I had forgotten the intricacies of class loader delegation. The only hard constraint on loading a class in multiple loaders is that `java.*` classes [must (only) be loaded by the boot loader](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.base/share/classes/java/lang/ClassLoader.java#L904).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908157130

From abimpoudis at openjdk.org  Wed Jan 24 14:58:55 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 14:58:55 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v43]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <kXlMFWjJh-MpZK9t-ca721LvRPPuhHsALOLkFQOddIg=.18978963-7202-4794-bd1a-f35ea41190f8@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:

  Check the range of the new types of switch through TypeTag.isInSuperClassesOf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/663c7a54..9b7fb7fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=41-42

  Stats: 12 lines in 2 files changed: 4 ins; 7 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 abimpoudis at openjdk.org  Wed Jan 24 14:58:57 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 14:58:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v41]
In-Reply-To: <BHwX3HCGZZiil_8ZBdwP0gcd5zJySeF_I4US6t245qE=.8c39683f-24cc-4d55-a2f8-a65c045984a1@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <Fn0a79OnPIS9UHbLHgM9_j8N-9UiNbLl6bcIAFDVXz4=.6de84c61-f6f9-421c-9de0-dd734686170f@github.com>
 <X7YK6q2mWcj3dg-dPbb8RGt6E3abus9-F9OR3rSon_M=.210a9adf-ee72-4484-a8a6-8b713df644f3@github.com>
 <01zQgnrUk9UigmTRH4Zijckme2pKW4gUsKMzhlGorsc=.2bb5c607-644b-457d-b8d6-e1f9b6a84025@github.com>
 <BHwX3HCGZZiil_8ZBdwP0gcd5zJySeF_I4US6t245qE=.8c39683f-24cc-4d55-a2f8-a65c045984a1@github.com>
Message-ID: <rYWNwhm54Xz-PhP2Txy7bGtUIwv9Q2PeIE1C7QgJlM4=.e2234b03-ce1d-4bb4-8c23-42a51a12c640@github.com>

On Wed, 24 Jan 2024 11:50:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Uh, I think this is a good catch.
>> 
>> I am not completely sure what the policy is, but here we are enhancing a non-preview method with some preview-based behavior. I would feel better if the method would refuse to work in the preview way when preview is not enabled. I.e. my opinion is that this should either be initialized to `jdk.internal.misc.PreviewFeatures.isEnabled()`, or `jdk.internal.misc.PreviewFeatures.ensureEnabled()` should be used appropriately.
>
> Used the `jdk.internal.misc.PreviewFeatures.isEnabled()` and remove an erroneous check in `typeSwitch`.

Addressed in https://github.com/openjdk/jdk/pull/15638/commits/663c7a54cec9ffd6ca468080f4d084e5fa4c9c3d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465039116

From abimpoudis at openjdk.org  Wed Jan 24 14:59:01 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 14:59:01 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
Message-ID: <2d_xzWvSpAAcu_RvESs8LipQDSvPL5A5N12t2VL6FMo=.b16e42ce-632a-4b1f-a7ab-a417ea39f86d@github.com>

On Wed, 24 Jan 2024 12:22:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set previewEnabled properly in SwitchBootstraps
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1924:
> 
>> 1922:     }
>> 1923:     // where
>> 1924:     static final Set<TypeTag> nonIntegralPrimitiveTypes = Set.of(
> 
> This feels like a method on TypeTag?

Addressed in https://github.com/openjdk/jdk/pull/15638/commits/9b7fb7fcdd2b393425267313622970ba709c645e

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4147:
> 
>> 4145:         }
>> 4146:         if (clazztype.isPrimitive()) {
>> 4147:             preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);
> 
> So, if I have a primitive instanceof, I get two preview warnings, one for the expression, and one for the pattern type? Shouldn't one be enough?

Meaning the `compiler.err.preview.feature.disabled.plural: (compiler.misc.feature.primitive.patterns)` error due to the two `if (clazztype.isPrimitive()) { preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);` ifs? Isn't it better to keep both, for better error reporting regarding the position? (i.e., which position do we report?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465034738
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465033188

From jiefu at openjdk.org  Wed Jan 24 15:25:49 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 24 Jan 2024 15:25:49 GMT
Subject: RFR: 8324647: Invalid test group of lib-test after JDK-8323515
Message-ID: <lqoo9p51wj_QzMyNAchjrku5gzrUY8gl3tRP_k9Shj4=.dd3b406a-3ec5-48e5-8cac-7fc22a772bb4@github.com>

This patch tries to fix the invalid test group definition of lib-test.
Please review.
Thanks.

-------------

Commit messages:
 - 8324647: Invalid test group of lib-test after JDK-8323515

Changes: https://git.openjdk.org/jdk/pull/17558/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324647
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17558.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17558/head:pull/17558

PR: https://git.openjdk.org/jdk/pull/17558

From abimpoudis at openjdk.org  Wed Jan 24 15:26:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:26:54 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@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 two additional commits since the last revision:

 - Enhance Javadoc of ExactConversionsSupport (2)
 - Enhance Javadoc of ExactConversionsSupport

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/9b7fb7fc..aa9b2fcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=42-43

  Stats: 33 lines in 1 file changed: 15 ins; 3 del; 15 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  Wed Jan 24 15:26:57 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:26:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <_hlWjNWAiPgvNTpwVWsBKURLCwySlIt5GoWiWKTJLRs=.3f069a48-2a82-408a-ba40-84d2b75b8ed3@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <_hlWjNWAiPgvNTpwVWsBKURLCwySlIt5GoWiWKTJLRs=.3f069a48-2a82-408a-ba40-84d2b75b8ed3@github.com>
Message-ID: <PXVNqX_5PEyNV1i_a5nAcALwty35cqU0mU3cZx1pUCc=.943eddb2-0902-4bd6-bad0-9020d0f83db8@github.com>

On Wed, 24 Jan 2024 12:13:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set previewEnabled properly in SwitchBootstraps
>
> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 37:
> 
>> 35:  * action at run time.
>> 36:  * <p>
>> 37:  * The run time conversion checks examine whether loss of information would
> 
> You provide examples for runtime conversions - it would be useful, before this para, to also have examples of an inexact conversion, an exact conversion and an unconditionally exact conversion (before diving into the details of how the runtime check is performed for floating points).

Addressed in https://github.com/openjdk/jdk/pull/15638/commits/5e48ea253bb7d8ae6fcc15a1ae7adb30475ff4ac 

Good point!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465080703

From jiefu at openjdk.org  Wed Jan 24 15:27:42 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 24 Jan 2024 15:27:42 GMT
Subject: RFR: 8323515: Create test alias "all" for all test roots [v3]
In-Reply-To: <CQUy1H5or0ZNkZzri_7qizVClqCPPtmlbRDWb5nYL48=.b82ae3cc-598b-4133-a875-4d837808b21e@github.com>
References: <aTmTcAjjZiRi2d6c0pQUxCZL_nOp5saaUpMjn1EMkd0=.a11a908c-6bc7-4152-af06-f5e102313aca@github.com>
 <9g7evWB6t3A8WAugPwgIP1gyisNBd1pGT9yFoC_0Z8M=.95b0574e-d163-4911-9c79-b58bf7301f7a@github.com>
 <CQUy1H5or0ZNkZzri_7qizVClqCPPtmlbRDWb5nYL48=.b82ae3cc-598b-4133-a875-4d837808b21e@github.com>
Message-ID: <CrDmWxnBRkCblGtgiPpOf09jOKzhHU1WDRKqm0UaA8k=.229ca15f-a9e5-49d9-a5dd-30b18f6e2222@github.com>

On Tue, 23 Jan 2024 17:03:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Catch-all -> All tests
>
> Thank you all!

Hi @shipilev , plese see https://github.com/openjdk/jdk/pull/17558 .
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17422#issuecomment-1908355476

From alanb at openjdk.org  Wed Jan 24 15:37:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Jan 2024 15:37:29 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <5jXTeDsMH-p2MOufqzCMIdfk2QIjwbQoXOwrblDDJVQ=.80af7dfe-d3ae-4dd9-8cda-f5e55ed6474d@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
 <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
 <IFyEWdA9yqoH10xLa4VryRW3rBWl5_mfFSBV2uup9jQ=.5efe865f-365c-44f7-82d9-04e9ec1020ac@github.com>
 <5jXTeDsMH-p2MOufqzCMIdfk2QIjwbQoXOwrblDDJVQ=.80af7dfe-d3ae-4dd9-8cda-f5e55ed6474d@github.com>
Message-ID: <5OWCQ7TabDzC57jr8P_7GBzRHcfX6ZEmXF4LK-R7k3c=.c7c9fbb3-0a7d-4773-8415-64689afeb6a1@github.com>

On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> You're right. I had forgotten the intricacies of class loader delegation. The only hard constraint on loading a class in multiple loaders is that `java.*` classes [must (only) be loaded by the boot loader](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.base/share/classes/java/lang/ClassLoader.java#L904).

Just to add that this restriction was relaxed in Java 9 to allow java.* classes be defined by the platform class loader. The code that is linked to here throws if the class loader is not the platform class loader. There isn't a user accessible ClassLoader object for the boot loader and testing `this == null` doesn't make sense.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908375220

From vromero at openjdk.org  Wed Jan 24 15:37:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 15:37:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
Message-ID: <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>

On Wed, 24 Jan 2024 15:26:54 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Enhance Javadoc of ExactConversionsSupport (2)
>  - Enhance Javadoc of ExactConversionsSupport

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 461:

> 459:                                     // Object o = ...
> 460:                                     // o instanceof Wrapped(float)
> 461:                                     cb.aload(0);

probably just a matter of style so up to you, but I don't like the mixing of low level code generation here with higher level logic. I would prefer to see the code generation be extracted if possible to helper methods and or a separate helper class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465102870

From vromero at openjdk.org  Wed Jan 24 15:40:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 15:40:37 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
Message-ID: <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>

On Wed, 24 Jan 2024 15:26:54 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Enhance Javadoc of ExactConversionsSupport (2)
>  - Enhance Javadoc of ExactConversionsSupport

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 471:

> 469:                                     // o instanceof float
> 470:                                     Label notNumber = cb.newLabel();
> 471:                                     cb.aload(0);

we are wiring constants into code generation: `0`, `3` etc, probably those won't change but I would prefer using static final fields or enums, that can be documented and changed easily in the future if needed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465107903

From eirbjo at openjdk.org  Wed Jan 24 15:49:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 24 Jan 2024 15:49:34 GMT
Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions
 called on existing MSDOS entries
Message-ID: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com>

Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170.

When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros.

The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately.

The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170).

-------------

Commit messages:
 - If the entry currently has no permissions set, don't try to merge permission bits with existing -1 bits

Changes: https://git.openjdk.org/jdk/pull/17556/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324635
  Stats: 31 lines in 2 files changed: 29 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17556/head:pull/17556

PR: https://git.openjdk.org/jdk/pull/17556

From abimpoudis at openjdk.org  Wed Jan 24 15:55:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:55:51 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@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 redundant test from checkUnconditionallyExact

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/aa9b2fcd..0fcdca82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=43-44

  Stats: 2 lines in 1 file changed: 0 ins; 1 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 abimpoudis at openjdk.org  Wed Jan 24 15:55:55 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 15:55:55 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
Message-ID: <9CCAFcGWzoHFi_4SaMN9i5KxnV3tSPnJAHvjQnZLE6I=.3db99d55-ded7-4a1a-a66e-fc6841af85fa@github.com>

On Wed, 24 Jan 2024 12:20:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set previewEnabled properly in SwitchBootstraps
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5046:
> 
>> 5044: 
>> 5045:         if (target.isPrimitive()) {
>> 5046:             return (source.isReference() && isSubtype(source, target)) ||
> 
> I'm a bit confused here - in here we have:
> * `target.isPrimitive()`
> * `source.isReference()`
> 
> So, isn't it the case that `isSubtype(source, target)` is always false?

Yes! Thanks for spotting. https://github.com/openjdk/jdk/pull/15638/commits/0fcdca8229c0db81fe3503770ed155a6aaa4f250

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465139800

From ihse at openjdk.org  Wed Jan 24 16:01:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 24 Jan 2024 16:01:32 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
Message-ID: <8Q2xMTEBHQGxSa-bA_ChMBt_cmx9aQ93QjtrPHdYabg=.ef6cfc53-a38b-4834-a5a1-2f9a0f6a0d7c@github.com>

On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use null to denote boot class loader as delegation parent

Build changes are trivially fine

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17520#pullrequestreview-1841751451

From mbalao at openjdk.org  Wed Jan 24 16:27:51 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 24 Jan 2024 16:27:51 GMT
Subject: RFR: 8315487: Security Providers Filter [v4]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <5s_qXFCYd69YbixEMMwRJAWLlKFb0cbQkqKYn0R5hUQ=.b6fa8fda-323d-4377-8fa4-966be409c6cb@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request with a new target base 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:

 - More clear text in invalid pattern exception.
 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/ea186c25..a7b27c35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=02-03

  Stats: 181690 lines in 3489 files changed: 100495 ins; 67363 del; 13832 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

PR: https://git.openjdk.org/jdk/pull/15539

From dnsimon at openjdk.org  Wed Jan 24 16:37:41 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Jan 2024 16:37:41 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
Message-ID: <pvG3BF_esXoybjU5pd_rTdIoNhbsajkueHuX2G19NBU=.f53785fd-bc1c-4dca-b099-a7953cedb315@github.com>

On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use null to denote boot class loader as delegation parent

I'm closing this PR as the Native Image use case https://bugs.openjdk.org/browse/JDK-8323832 was opened for can be solved with an appropriately crafted custom loader that does not delegate loading of JVMCI classes.

Thanks for the reviews anyway, especially @xxDark for highlighting that this change is unnecessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908498530

From dnsimon at openjdk.org  Wed Jan 24 16:37:43 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Jan 2024 16:37:43 GMT
Subject: Withdrawn: 8323832: Load JVMCI with the platform class loader
In-Reply-To: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
Message-ID: <wyywKJKbm8xHC6w-s_gdS3ZFrI0d9W_I2SyW32hZGxE=.0a280db4-d1df-4a9c-8914-1348eb7783c9@github.com>

On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by `LoadAlternativeJVMCI.java`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17520

From mbalao at openjdk.org  Wed Jan 24 16:39:46 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 24 Jan 2024 16:39:46 GMT
Subject: RFR: 8315487: Security Providers Filter [v5]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <PcUwNyScfOlfpACImcwNIZQEYx7Fl7ig2VslyIXnGpg=.00298f7c-a413-41ee-aeda-2ca3f76a904d@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Copyright dates update.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/a7b27c35..35516004

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=03-04

  Stats: 21 lines in 21 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

PR: https://git.openjdk.org/jdk/pull/15539

From shade at openjdk.org  Wed Jan 24 17:25:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 17:25:26 GMT
Subject: RFR: 8324647: Invalid test group of lib-test after JDK-8323515
In-Reply-To: <lqoo9p51wj_QzMyNAchjrku5gzrUY8gl3tRP_k9Shj4=.dd3b406a-3ec5-48e5-8cac-7fc22a772bb4@github.com>
References: <lqoo9p51wj_QzMyNAchjrku5gzrUY8gl3tRP_k9Shj4=.dd3b406a-3ec5-48e5-8cac-7fc22a772bb4@github.com>
Message-ID: <VfJlIx4CngZvP7aRkEpqVonWy_EydH67TiZqCV6WsiE=.024ebe71-9e1d-4cc1-9c36-294bcac6b5c6@github.com>

On Wed, 24 Jan 2024 15:20:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> This patch tries to fix the invalid test group definition of lib-test.
> Please review.
> Thanks.

Ooof. I wonder how that happened. This would not show up before we try to run the actual libtest tests. What is extra wild is that GHA reports green, even though the logs say that TEST.groups is incorrect! I am going to go and fix that...

The fix looks good and trivial. Thanks for catching it!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17558#pullrequestreview-1841971948

From vromero at openjdk.org  Wed Jan 24 17:32:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 17:32:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 redundant test from checkUnconditionallyExact

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 168:

> 166:         requireNonNull(labels);
> 167: 
> 168:         labels = labels.clone();

just curious, why do we need to clone this array?

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 405:

> 403:      */
> 404:     @SuppressWarnings("removal")
> 405:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {

again a matter of style but it seems to me that the huge lambda inside of this method, starting in line 409, really wants to be a separate helper method. That will probably be a better refactoring as we won't be mixing byte code generation with method handles manipulation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465292275
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465308346

From vromero at openjdk.org  Wed Jan 24 17:32:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 17:32:41 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
Message-ID: <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>

On Wed, 24 Jan 2024 15:34:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Enhance Javadoc of ExactConversionsSupport (2)
>>  - Enhance Javadoc of ExactConversionsSupport
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 461:
> 
>> 459:                                     // Object o = ...
>> 460:                                     // o instanceof Wrapped(float)
>> 461:                                     cb.aload(0);
> 
> probably just a matter of style so up to you, but I don't like the mixing of low level code generation here with higher level logic. I would prefer to see the code generation be extracted if possible to helper methods and or a separate helper class.

see my other comment above that I think supersedes this one

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465309941

From darcy at openjdk.org  Wed Jan 24 18:17:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 18:17:35 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 redundant test from checkUnconditionallyExact

test/micro/org/openjdk/bench/jdk/preview/patterns/Exactness.java line 1:

> 1: /*

The exactness predicates should have regression tests on their correct operation in addition to any performance testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465361951

From abimpoudis at openjdk.org  Wed Jan 24 18:17:35 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 18:17:35 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
Message-ID: <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>

On Wed, 24 Jan 2024 18:12:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> test/micro/org/openjdk/bench/jdk/preview/patterns/Exactness.java line 1:
> 
>> 1: /*
> 
> The exactness predicates should have regression tests on their correct operation in addition to any performance testing.

I have this regarding numeric values

[test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465363618

From darcy at openjdk.org  Wed Jan 24 18:23:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Jan 2024 18:23:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
 <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>
Message-ID: <_UoKEsRH6GvJlMfK10Q486qghFcXnD-MgBjEIAONvZI=.d9bde165-4546-48b2-aed8-a601a11fe044@github.com>

On Wed, 24 Jan 2024 18:14:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> I have this regarding numeric values. Is it the kind of test you have in mind?
> 
> [test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)

IMO, the library methods merit some of their own dedicated direct testing (since an end user could in principle call them too) in addition to indirect tests of their operation via javac's code generation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465371034

From vromero at openjdk.org  Wed Jan 24 18:28:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 18:28:35 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 redundant test from checkUnconditionallyExact

test/langtools/tools/javac/patterns/CastConversionMatch.java line 6:

> 4:  * @summary Match which involves a cast conversion
> 5:  * @compile/fail/ref=CastConversionMatch.out -XDrawDiagnostics CastConversionMatch.java
> 6:  * @compile --enable-preview --source ${jdk.version} CastConversionMatch.java */

@enablePreview?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465374452

From abimpoudis at openjdk.org  Wed Jan 24 18:28:36 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 18:28:36 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>
Message-ID: <U8aryv_FTnSU0nDMo5qObH1n3vNokjUakmOut35iaI4=.8cebebd2-9501-47aa-a48d-36eeddf3a039@github.com>

On Wed, 24 Jan 2024 18:24:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> test/langtools/tools/javac/patterns/CastConversionMatch.java line 6:
> 
>> 4:  * @summary Match which involves a cast conversion
>> 5:  * @compile/fail/ref=CastConversionMatch.out -XDrawDiagnostics CastConversionMatch.java
>> 6:  * @compile --enable-preview --source ${jdk.version} CastConversionMatch.java */
> 
> @enablePreview?

I have two compile commands. Wanted to test one with and one without preview.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465376180

From vromero at openjdk.org  Wed Jan 24 18:31:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 18:31:43 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
Message-ID: <yiE3AEKqj_mjHkWqs86pnB25yVblUBtAqlbEcQB4drA=.dac7be0b-8799-47b5-ae76-90b137c03dd7@github.com>

On Wed, 24 Jan 2024 15:55:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 redundant test from checkUnconditionallyExact

test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithRecordPatterns.java line 28:

> 26:  * @bug 8304487
> 27:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
> 28:  * @compile -g --enable-preview -source ${jdk.version} PrimitiveInstanceOfPatternOpWithRecordPatterns.java

not sure why you need `-g` here

test/langtools/tools/javac/patterns/PrimitiveInstanceOfTypeComparisonOp.java line 28:

> 26:  * @bug 8304487
> 27:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
> 28:  * @compile -g --enable-preview -source ${jdk.version} PrimitiveInstanceOfTypeComparisonOp.java

`-g`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465376609
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465378575

From abimpoudis at openjdk.org  Wed Jan 24 18:41:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 18:41:54 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v46]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <pYINAEHW4gCCpSRz5jRT8tRGUTSFIZcszNLV1Da4BuA=.664de2e1-52da-4f7e-bdb4-27dc546a7c2b@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 test parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/0fcdca82..ea31a804

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=44-45

  Stats: 53 lines in 7 files changed: 5 ins; 0 del; 48 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 mcimadamore at openjdk.org  Wed Jan 24 18:51:29 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 18:51:29 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
Message-ID: <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>

On Wed, 24 Jan 2024 10:33:05 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

Naive question: the right way to use this would be almost invariably be like this:

if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
    // fast-path
}
// slow path


Right? Then the expectation is that during interpreter and C1, `isCompileConstant` always returns false, so we just never take the fast path (but we probably still pay for the branch, right?). And, when we get to C2 and this method is inlined, at this point we know that either `foo` is constant or not. If it is constant we can check other conditions on foo (which presumably is cheap because `foo` is constant) and maybe take the fast-path. In both cases, there's no branch in the generated code because we know "statically" when inlining if `foo` has the right shape or not. Correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1908724632

From shade at openjdk.org  Wed Jan 24 18:51:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 18:51:31 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <9iDFu8I4w_i1Uso5q7oEi0Le1JvgDNgNyuSZlmKQiuE=.5739d448-fc73-4bcf-bec8-26b3a1b75d21@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
 <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>
 <9iDFu8I4w_i1Uso5q7oEi0Le1JvgDNgNyuSZlmKQiuE=.5739d448-fc73-4bcf-bec8-26b3a1b75d21@github.com>
Message-ID: <WxiAGRmZe3zH9xWJHmrwz20Q_nrbHkLG3CU6624u7nY=.2cd1b7d0-2aaa-4a30-92a0-7027d500c0ed@github.com>

On Wed, 24 Jan 2024 07:15:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This seems really weird to me for Java code. The method doesn't get the original "expression" it only gets the value of that expression after it has been evaluated. Is there some kind of weird "magic" happening here?
>
> @dholmes-ora Indeed it's a compiler magic, albeit not really weird. While the method execution only receives the evaluated value of `expr`, the method compilation has the expression in its original form. As a result, it can determine the result based on this information.

It is still weird to talk about expressions at this level. We really check if the value is constant, like the method name suggests now. Yes, this implicitly tests that the expression that produced that value is fully constant-folded. But that's a detail that we do not need to capture here. Let's rename `expr` -> `val`, and tighten up the javadoc for the method to mention we only test the constness of the final value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1465401456

From shade at openjdk.org  Wed Jan 24 18:51:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 18:51:32 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
Message-ID: <uPMadJEE8mU1eGKNQMX8aUI5q-6u8vx9W-z8NvjL0HM=.b7b1a937-9b92-44c9-816e-5b7979cd9a4e@github.com>

On Wed, 24 Jan 2024 10:33:05 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

src/java.base/share/classes/jdk/internal/vm/ConstantSupport.java line 32:

> 30: /**
> 31:  * Just-in-time-compiler-related queries
> 32:  */

This looks like a stale comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1465397036

From mcimadamore at openjdk.org  Wed Jan 24 18:54:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 18:54:28 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
Message-ID: <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>

On Wed, 24 Jan 2024 18:48:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Naive question: the right way to use this would be almost invariably be like this:
> 
> ```
> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>     // fast-path
> }
> // slow path
> ```
> 
> Right? Then the expectation is that during interpreter and C1, `isCompileConstant` always returns false, so we just never take the fast path (but we probably still pay for the branch, right?). And, when we get to C2 and this method is inlined, at this point we know that either `foo` is constant or not. If it is constant we can check other conditions on foo (which presumably is cheap because `foo` is constant) and maybe take the fast-path. In both cases, there's no branch in the generated code because we know "statically" when inlining if `foo` has the right shape or not. Correct?

P.S. if this is correct, please consider adding something along those lines in the javadoc of `isCompileConstant`; as it stands it is a bit obscure to understand how this thing might be used, and what are the common pitfalls to avoid when using it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1908729766

From duke at openjdk.org  Wed Jan 24 18:55:38 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 24 Jan 2024 18:55:38 GMT
Subject: Integrated: 8322149: ConcurrentHashMap smarter presizing for copy
 constructor and putAll
In-Reply-To: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
References: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>
Message-ID: <5SzKrzgFkRj6Fgex-JFdDG-0MJ0N8qjTdutrQucg0Es=.0e3c828e-1f88-439e-8b08-3e2e6152cdca@github.com>

On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao <duke at openjdk.org> wrote:

> 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%.
> 
> ### JMH results for testPutAll (size = 10000)
> 
> before patch:
> 
> 
> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>   4315291.542 ?(99.9%) 336034.190 ns/op [Average]
>   (min, avg, max) = (3974688.194, 4315291.542, 4871772.209), stdev = 314326.589
>   CI (99.9%): [3979257.352, 4651325.731] (assumes normal distribution)
> 
> 
> after patch:
> 
> 
> Result "org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
>   3006955.723 ?(99.9%) 271757.969 ns/op [Average]
>   (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev = 254202.573
>   CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
> 
> 
> Average time is decreased about 30%.

This pull request has now been integrated.

Changeset: c432dc00
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c432dc008bb3a2d3fe6b46617ad64a2999ae366c
Stats:     27 lines in 2 files changed: 24 ins; 1 del; 2 mod

8322149: ConcurrentHashMap smarter presizing for copy constructor and putAll

Reviewed-by: shade, simonis

-------------

PR: https://git.openjdk.org/jdk/pull/17116

From shade at openjdk.org  Wed Jan 24 18:58:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Jan 2024 18:58:28 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
Message-ID: <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>

On Wed, 24 Jan 2024 18:51:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Naive question: the right way to use this would be almost invariably be like this:
> 
> ```
> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>     // fast-path
> }
> // slow path
> ```
> 
> Right? 

Yes, I think so.

> Then the expectation is that during interpreter and C1, `isCompileConstant` always returns false, so we just never take the fast path (but we probably still pay for the branch, right?). 

Yes, I think so. For C1, we would still prune the "dead" path, because C1 is able to know that `if (false)` is never taken. We do pay with the branch and the method call in interpreter. (There are ways to special-case these intrinsics for interpreter too, if we choose to care.)

> And, when we get to C2 and this method is inlined, at this point we know that either `foo` is constant or not. If it is constant we can check other conditions on foo (which presumably is cheap because `foo` is constant) and maybe take the fast-path. In both cases, there's no branch in the generated code because we know "statically" when inlining if `foo` has the right shape or not. Correct?

Yes. I think the major use would be using `constexpr`-like code on "const" path, so that the entire "const" branch constant-folds completely. In [my experiments](https://github.com/openjdk/jdk/pull/17527#issuecomment-1906379544) with `Integer.toString` that certainly happens. But that is not a requirement, and we could probably still reap some benefits from partial constant folds; but at that point we would need to prove that a "partially const" path is better than generic "non-const" path under the same conditions.

I agree it would be convenient to put some examples in javadoc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1908736651

From simonis at openjdk.org  Wed Jan 24 19:09:25 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 24 Jan 2024 19:09:25 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <3CzOoMtSu0zffIIiUaz1PQFJLVN_pdeRHKpRAqDMnn8=.c0eb6f8f-e5ac-4030-9021-608488933a30@github.com>

On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao <duke at openjdk.org> wrote:

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.

> The current benchmark and the change don't really cover the case where many keys exist in _both_ maps. Could you add a benchmark for that? Also `int s = size() + m.size();` can overflow now, leading to different behavior. It might make sense to just cap the value?

@SirYwell , I agree with the "*overflow*" part which could easily be fixed by changing the type of `s` to double.

I don't understand the first part about "*the case where many keys exist in _both_ maps*". The benchmark and the results presented in the PR are for a hash map with 100000 elements into which we insert (i.e. `putAll()`) another 100000 elements. Or am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1908751920

From abimpoudis at openjdk.org  Wed Jan 24 19:33:52 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 19:33:52 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v47]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@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:

  Introduce ExactnessConversionsSupportTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ea31a804..4e5ac772

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=45-46

  Stats: 243 lines in 2 files changed: 236 ins; 0 del; 7 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  Wed Jan 24 19:36:33 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 19:36:33 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <_UoKEsRH6GvJlMfK10Q486qghFcXnD-MgBjEIAONvZI=.d9bde165-4546-48b2-aed8-a601a11fe044@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <_1NOO9WJQnrGflaFyaId1xfkeiijY6BAvtoIdwLhAiE=.1e6acede-f0bb-47c5-9745-f34cc82f25ed@github.com>
 <lQBIfpEe1-paJ_FbwCabZD7bRT8BwSzTvmlqfnDCHwM=.6e47de52-b25e-4f2e-a46c-42bceebbebcf@github.com>
 <_UoKEsRH6GvJlMfK10Q486qghFcXnD-MgBjEIAONvZI=.d9bde165-4546-48b2-aed8-a601a11fe044@github.com>
Message-ID: <cR5yggfMO79giT3ZnM4r_GdMBWmgj2aZBRB_kO8vE64=.c00efefb-e680-4454-81bb-66c0971da805@github.com>

On Wed, 24 Jan 2024 18:21:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I have this regarding numeric values. Is it the kind of test you have in mind?
>> 
>> [test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)
>
>> I have this regarding numeric values. Is it the kind of test you have in mind?
>> 
>> [test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java](https://github.com/openjdk/jdk/pull/15638/files#diff-0c7b37309d920b4c1af93789aed337c9eb259ad31977b9ef395e7b8c4b47a6d6)
> 
> IMO, the library methods merit some of their own dedicated direct testing (since an end user could in principle call them too) in addition to indirect tests of their operation via javac's code generation.

I did a translation of that file into [ExactnessConversionsSupportTest.java](https://github.com/openjdk/jdk/pull/15638/commits/4e5ac772417a2e50d47fd6fa8feb363a6bffa88c#diff-c24740028b9956d2dd2947907713f5e2d8681e8762f6d8e26e4faf2ded3979a8). What else could I add?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465445954

From psandoz at openjdk.org  Wed Jan 24 19:40:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Jan 2024 19:40:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <WxiAGRmZe3zH9xWJHmrwz20Q_nrbHkLG3CU6624u7nY=.2cd1b7d0-2aaa-4a30-92a0-7027d500c0ed@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
 <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>
 <9iDFu8I4w_i1Uso5q7oEi0Le1JvgDNgNyuSZlmKQiuE=.5739d448-fc73-4bcf-bec8-26b3a1b75d21@github.com>
 <WxiAGRmZe3zH9xWJHmrwz20Q_nrbHkLG3CU6624u7nY=.2cd1b7d0-2aaa-4a30-92a0-7027d500c0ed@github.com>
Message-ID: <-msFouQp2kpWPf6LTKgbDAeLPUkfET6wVesLbAz-6T4=.54ca377c-2e49-4229-a060-daa34485eead@github.com>

On Wed, 24 Jan 2024 18:48:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @dholmes-ora Indeed it's a compiler magic, albeit not really weird. While the method execution only receives the evaluated value of `expr`, the method compilation has the expression in its original form. As a result, it can determine the result based on this information.
>
> It is still weird to talk about expressions at this level. We really check if the value is constant, like the method name suggests now. Yes, this implicitly tests that the expression that produced that value is fully constant-folded. But that's a detail that we do not need to capture here. Let's rename `expr` -> `val`, and tighten up the javadoc for the method to mention we only test the constness of the final value.

I agree. All values are produced by evaluating expressions. In this case we want to query whether a value produced by the compiler evaluating its expression is a constant value (inputs to the expression are constants and the expression had no material side-effects). Meaning if the method returns true then we could use that knowledge in subsequent expressions that may also produce constants or some specific behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1465449454

From hgreule at openjdk.org  Wed Jan 24 19:43:25 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 24 Jan 2024 19:43:25 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <JTZsn4AKOaEELex8uktn0FFUOwHjBV6Ng3CJiQWtLuI=.ea20c430-19e7-4936-ba42-abcd31c616f6@github.com>

On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao <duke at openjdk.org> wrote:

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.

> I don't understand the first part about "_the case where many keys exist in _both_ maps_". The benchmark and the results presented in the PR are for a hash map with 100000 elements into which we insert (i.e. `putAll()`) another 100000 elements. Or am I missing something?

Sorry, @simonis. I meant the situation where one key is present in both maps, for many keys. That would cause large resizes while only few entries will be actually added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1908799138

From liach at openjdk.org  Wed Jan 24 19:58:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Jan 2024 19:58:26 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <HBs04-RFTZ-s-2BfRaYISqd_x2fvRGeV3BBkQSM0i7I=.f1e9bd5b-1e1c-4d87-a87f-7ad29482c5ba@github.com>

On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao <duke at openjdk.org> wrote:

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.

Then we might need some statistics on how often `putAll` replaces existing mappings, ranging from none at all to completely. For example, `Collectors.toMap` would never replace existing mappings, even though it doesn't use `putAll` (it can probably call putAll and throw exception if the new size isn't 2 old sizes added up)

The current allocation assumes putting replaces all existing mappings, which I don't think is quite applicable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1908819980

From rriggs at openjdk.org  Wed Jan 24 20:16:45 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 Jan 2024 20:16:45 GMT
Subject: RFR: 8324657: Intermittent OOME on exception message create
Message-ID: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>

When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
Explicit use of String.concat() call can improve exception handling.

Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

-------------

Commit messages:
 - More discriptive comment
 - When handling an OutOfMemoryError due to off-heap allocation failure

Changes: https://git.openjdk.org/jdk/pull/17522/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17522&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324657
  Stats: 14 lines in 1 file changed: 7 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17522/head:pull/17522

PR: https://git.openjdk.org/jdk/pull/17522

From lancea at openjdk.org  Wed Jan 24 20:16:45 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 24 Jan 2024 20:16:45 GMT
Subject: RFR: 8324657: Intermittent OOME on exception message create
In-Reply-To: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
References: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
Message-ID: <E0k8Lp9_PE0xjPMgUQG3aMpO8kPA3zE-S6ivZQDKbpk=.c2c9f334-a351-4fd7-bf7f-a92f1cc84bdc@github.com>

On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
> Explicit use of String.concat() call can improve exception handling.
> 
> Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17522#pullrequestreview-1837408236

From vromero at openjdk.org  Wed Jan 24 20:31:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jan 2024 20:31:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <U8aryv_FTnSU0nDMo5qObH1n3vNokjUakmOut35iaI4=.8cebebd2-9501-47aa-a48d-36eeddf3a039@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <x2nZYFwy9fivbgvwqXt0sEGEnGg7Xp7_IE78gEdTJ5Y=.1e48ca08-c5ca-407c-bb7d-d2f09375acdc@github.com>
 <U8aryv_FTnSU0nDMo5qObH1n3vNokjUakmOut35iaI4=.8cebebd2-9501-47aa-a48d-36eeddf3a039@github.com>
Message-ID: <jBwhPfKSEwDR6ybhYpXYm22zinGsk83k2s0dlnHSExs=.a6bd49e0-6fe3-412c-af00-b23207437f29@github.com>

On Wed, 24 Jan 2024 18:26:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/CastConversionMatch.java line 6:
>> 
>>> 4:  * @summary Match which involves a cast conversion
>>> 5:  * @compile/fail/ref=CastConversionMatch.out -XDrawDiagnostics CastConversionMatch.java
>>> 6:  * @compile --enable-preview --source ${jdk.version} CastConversionMatch.java */
>> 
>> @enablePreview?
>
> I have two compile commands. Wanted to test one with and one without preview.

right missed that sorry

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465499180

From duke at openjdk.org  Wed Jan 24 20:40:36 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 24 Jan 2024 20:40:36 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v2]
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <Jpz5JYd50nXkveOqi6oX7WmH7Qtdacp-IeD_qpRXifw=.01a621a3-b81b-40b8-a3f2-8bdaf1a83ae6@github.com>

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.

Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark with all duplicate keys

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17544/files
  - new: https://git.openjdk.org/jdk/pull/17544/files/d1ad90cd..a74c10da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=00-01

  Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544

PR: https://git.openjdk.org/jdk/pull/17544

From aturbanov at openjdk.org  Wed Jan 24 20:46:25 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 24 Jan 2024 20:46:25 GMT
Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized'
 unnecessarily
In-Reply-To: <Leses-SHKnelU4_Ma1Ak6YfbF1YxcQFpq8MwXQus6EY=.207285f8-db0b-43a9-a4c9-13241fa0c9c1@github.com>
References: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
 <oeypt73pZ3oIF1BQU-Nnn8IO5Jb5kvZ4w5ngam36TBs=.a7141969-655c-41b4-8dca-94cca69d6662@github.com>
 <Leses-SHKnelU4_Ma1Ak6YfbF1YxcQFpq8MwXQus6EY=.207285f8-db0b-43a9-a4c9-13241fa0c9c1@github.com>
Message-ID: <I0A4pLB62WRJLL6pbZB-IW92I8pQ-QSnD5xJhFJSkyA=.9aabf48f-15e8-47b0-b287-df68050ca0ca@github.com>

On Wed, 17 Jan 2024 18:19:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TimeZone.java line 629:
>> 
>>> 627:      */
>>> 628:     public static String[] getAvailableIDs(int rawOffset) {
>>> 629:         return ZoneInfo.getAvailableIDs(rawOffset);
>> 
>> BTW can we call `ZoneInfoFile.getZoneIds` here directly? 
>> `ZoneInfo.getAvailableIDs` bridge seems redudnant.
>
> `TimeZone` is an abstract class, and `ZoneInfo` is an implementation. So to me, it is clearer to call the overriden method in the implementation even though the reason you mentioned.

>From OOP point of view - it's strange to call subclass method from a super class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17441#discussion_r1465516080

From duke at openjdk.org  Wed Jan 24 20:57:26 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 24 Jan 2024 20:57:26 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <3CzOoMtSu0zffIIiUaz1PQFJLVN_pdeRHKpRAqDMnn8=.c0eb6f8f-e5ac-4030-9021-608488933a30@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <3CzOoMtSu0zffIIiUaz1PQFJLVN_pdeRHKpRAqDMnn8=.c0eb6f8f-e5ac-4030-9021-608488933a30@github.com>
Message-ID: <AzY4635e1Mr3o5yhvRGWWpEnMVUoNW1gIp634fT_hKE=.e97f8805-1117-4f54-9bc2-4cd33e69423d@github.com>

On Wed, 24 Jan 2024 19:06:49 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> The current benchmark and the change don't really cover the case where many keys exist in _both_ maps. Could you add a benchmark for that?

I added a benchmark that assumes the worse case. Please see the top post. Yes, this change is not always beneficial. I'd like to think the original benchmark, which uses random keys, is closer to real life scenarios. There may be some duplicate keys, but most keys are unique. But this is just my intuition, I do not have data to back this up.

One solution would be to loop through both maps and count number of unique keys. My guess is that this would mostly add unnecessary computations. We can compromise with something like `size() / 2 + m.size()`. My guess is the current aggressive approach is the best most of the time, but I don't have strong opinions and am happy to take suggestions.

> Also `int s = size() + m.size();` can overflow now, leading to different behavior. It might make sense to just cap the value?

Is it necessary? We can go with @simonis 's suggestion. I think if we move forward with this, it would make sense to change all instances of `size` to long type, which would then suggest we should change the `Map::size()` api to return a long. The reason I am not concerned about overflow is that the Map API implies that we should only care about maps with at most 2^32 items.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1908899013

From duke at openjdk.org  Wed Jan 24 21:01:26 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 24 Jan 2024 21:01:26 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <HBs04-RFTZ-s-2BfRaYISqd_x2fvRGeV3BBkQSM0i7I=.f1e9bd5b-1e1c-4d87-a87f-7ad29482c5ba@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <HBs04-RFTZ-s-2BfRaYISqd_x2fvRGeV3BBkQSM0i7I=.f1e9bd5b-1e1c-4d87-a87f-7ad29482c5ba@github.com>
Message-ID: <Xgu_5bNEvYgMQAGrDfpO8M7PAmLm-Og52nMdjUbyPw8=.244e6a63-961f-4270-8220-1e01a40a200f@github.com>

On Wed, 24 Jan 2024 19:55:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Then we might need some statistics on how often `putAll` replaces existing mappings, ranging from none at all to completely. For example, `Collectors.toMap` would never replace existing mappings, even though it doesn't use `putAll` (it can probably call putAll and throw exception if the new size isn't 2 old sizes added up)
> 
> The current allocation assumes putting replaces all existing mappings, which I don't think is quite applicable.

I do not think we care whetherd mappings are getting replaced. We care about the number of unique keys between the two maps, which determines the final size of the map.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1908904298

From lmesnik at openjdk.org  Wed Jan 24 21:31:24 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 24 Jan 2024 21:31:24 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
Message-ID: <-quimoVBzziosvz8NKyrp0fop7T9ZRDg4SJo1wif6aw=.77948f6f-0728-4e57-ae98-5c5472f435ee@github.com>

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
> 
> I provisionally call this flag `external-dep`, but I am open for other suggestions.
> 
> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
> 
> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
> 
> Additional testing:
>  - [x] `make test TEST=applications/` fails
>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17421#pullrequestreview-1842419609

From mcimadamore at openjdk.org  Wed Jan 24 21:37:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 21:37:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v42]
In-Reply-To: <2d_xzWvSpAAcu_RvESs8LipQDSvPL5A5N12t2VL6FMo=.b16e42ce-632a-4b1f-a7ab-a417ea39f86d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <eX4M1biATCbjIItmAVwL5gKAsZ33HIBXxfLmr9sIrRg=.a709c2e7-eacc-43a0-bb3a-f92f2d25dd2d@github.com>
 <Dhw8CycMOFXQKSxVbYBB1W0Q-dI19ioxGwIVEUN7iMc=.79c04b3b-5826-4aff-9ae8-ad552bc0de1e@github.com>
 <2d_xzWvSpAAcu_RvESs8LipQDSvPL5A5N12t2VL6FMo=.b16e42ce-632a-4b1f-a7ab-a417ea39f86d@github.com>
Message-ID: <k0icjkwLTcTlyIRZgFeTUt8OCydRVDwhc13wdlr04_U=.75aa6aab-8160-4a41-96c9-44bcfcfbbd42@github.com>

On Wed, 24 Jan 2024 14:53:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4147:
>> 
>>> 4145:         }
>>> 4146:         if (clazztype.isPrimitive()) {
>>> 4147:             preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);
>> 
>> So, if I have a primitive instanceof, I get two preview warnings, one for the expression, and one for the pattern type? Shouldn't one be enough?
>
> Meaning the `compiler.err.preview.feature.disabled.plural: (compiler.misc.feature.primitive.patterns)` error due to the two `if (clazztype.isPrimitive()) { preview.checkSourceLevel(tree.pattern.pos(), Feature.PRIMITIVE_PATTERNS);` ifs? Isn't it better to keep both, for better error reporting regarding the position? (i.e., which position do we report?)

What I mean is that, looking at the code, it seems like:

int x;
if (x instanceof int y) ...

will generate two warnings. Perhaps that's what we want, but it seems a bit on the heavy-side, subjectively. Anyway, no need to take any action.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465569066

From iris at openjdk.org  Wed Jan 24 21:43:26 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 24 Jan 2024 21:43:26 GMT
Subject: RFR: 8324657: Intermittent OOME on exception message create
In-Reply-To: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
References: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
Message-ID: <JZopIRZlomUVOuISyDv4EewUi2aCgO1fjcqcjVb1KXM=.cfd34df5-98ef-4f19-a7cd-383651309472@github.com>

On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
> Explicit use of String.concat() call can improve exception handling.
> 
> Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17522#pullrequestreview-1842436256

From dholmes at openjdk.org  Wed Jan 24 21:43:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Jan 2024 21:43:35 GMT
Subject: RFR: 8323832: Load JVMCI with the platform class loader [v2]
In-Reply-To: <5jXTeDsMH-p2MOufqzCMIdfk2QIjwbQoXOwrblDDJVQ=.80af7dfe-d3ae-4dd9-8cda-f5e55ed6474d@github.com>
References: <6mck217Pb518xgiP3lwwpFsM7cIG848O0wd32BqWt6s=.22665c42-b3be-4ebf-b48c-033ecdbf50e9@github.com>
 <3ssi94PwDDJSjpoDwCyVTvPEicBzNYMtTFZQLPPS8X4=.fe74293a-224d-47f8-a9c9-0bb2206a817b@github.com>
 <SzcS_wa4khX7RezB-OE3wZpG3b_u_eclRHvcmN77EpM=.44eef55e-6a38-402c-9db4-1ccedcb1005e@github.com>
 <jbEP6cguR1kBHsaX6SvKvIocdobASg9bBOycgQQY9Cw=.c9d67a6e-e7f5-4f09-aaf7-f87c70ea27ea@github.com>
 <IFyEWdA9yqoH10xLa4VryRW3rBWl5_mfFSBV2uup9jQ=.5efe865f-365c-44f7-82d9-04e9ec1020ac@github.com>
 <5jXTeDsMH-p2MOufqzCMIdfk2QIjwbQoXOwrblDDJVQ=.80af7dfe-d3ae-4dd9-8cda-f5e55ed6474d@github.com>
Message-ID: <r_lnPMbKgzbIkik-LfLM_Hl58UzEmog9WYhhpHOu7Jw=.44e0dea4-0d76-41a3-8a25-f79ac662f0db@github.com>

On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> You need to check if class is already loaded by trying findLoadedClass first.

Thanks @xxDark . I knew it should work. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908961416

From mcimadamore at openjdk.org  Wed Jan 24 21:50:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 Jan 2024 21:50:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v47]
In-Reply-To: <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>
Message-ID: <IgYYtX0n0ZeKB0Bw-bGdMnnbttKgWgCFPCmvYCr5rjs=.bee7a753-1579-4962-b226-43465c062313@github.com>

On Wed, 24 Jan 2024 19:33:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Introduce ExactnessConversionsSupportTest

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 33:

> 31:  * said to be unconditionally exact.
> 32:  * <p>
> 33:  * For example, a conversion from {@code int} to {@code byte} for the value 10

Very nice text!

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5045:

> 5043:         }
> 5044: 
> 5045:         if (target.isPrimitive()) {

nit: maybe now a ternary expression can be used

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465579085
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465580461

From hgreule at openjdk.org  Wed Jan 24 21:56:25 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 24 Jan 2024 21:56:25 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <AzY4635e1Mr3o5yhvRGWWpEnMVUoNW1gIp634fT_hKE=.e97f8805-1117-4f54-9bc2-4cd33e69423d@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <3CzOoMtSu0zffIIiUaz1PQFJLVN_pdeRHKpRAqDMnn8=.c0eb6f8f-e5ac-4030-9021-608488933a30@github.com>
 <AzY4635e1Mr3o5yhvRGWWpEnMVUoNW1gIp634fT_hKE=.e97f8805-1117-4f54-9bc2-4cd33e69423d@github.com>
Message-ID: <lJGdahlhaU7Ycu_l2pfPCa3-7jsNvm-MXp6Jn0BPWAA=.c5b8e89e-2c64-48d7-b7e5-a17f8fa9f58c@github.com>

On Wed, 24 Jan 2024 20:54:43 GMT, Joshua Cao <duke at openjdk.org> wrote:

> > The current benchmark and the change don't really cover the case where many keys exist in _both_ maps. Could you add a benchmark for that?
> 
> I added a benchmark that assumes the worse case. Please see the top post. Yes, this change is not always beneficial. I'd like to think the original benchmark, which uses random keys, is closer to real life scenarios. There may be some duplicate keys, but most keys are unique. But this is just my intuition, I do not have data to back this up.

Thanks, I don't have any data on in either, I just think it's worth to consider such cases. But the regression is probably acceptable here.

> One solution would be to loop through both maps and count number of unique keys. My guess is that this would mostly add unnecessary computations. We can compromise with something like `size() / 2 + m.size()`. My guess is the current aggressive approach is the best most of the time, but I don't have strong opinions and am happy to take suggestions.

Something like that might make sense, but I doubt it will be possible to find a sweet spot that works *always*. Doing more complex calculation likely doesn't help.

> > Also `int s = size() + m.size();` can overflow now, leading to different behavior. It might make sense to just cap the value?
> 
> Is it necessary? We can go with @simonis 's suggestion. I think if we move forward with this, it would make sense to change all instances of `size` to long type, which would then suggest we should change the `Map::size()` api to return a long. The reason I am not concerned about overflow is that the Map API implies that we should only care about maps with at most 2^32 items.

With the current implementation it is necessary, especially when considering duplicated keys. The current implementation seems to just skip inserting anything if `s <= 0`, so an overflow would cause different behavior now. Maybe it makes sense to add a early return at the top of the method if `m` is empty and remove the `if (s > 0)`?

Using `double` would make sense because the value is used in double contexts afterwards anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1908977135

From jiefu at openjdk.org  Wed Jan 24 23:24:34 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 24 Jan 2024 23:24:34 GMT
Subject: RFR: 8324647: Invalid test group of lib-test after JDK-8323515
In-Reply-To: <VfJlIx4CngZvP7aRkEpqVonWy_EydH67TiZqCV6WsiE=.024ebe71-9e1d-4cc1-9c36-294bcac6b5c6@github.com>
References: <lqoo9p51wj_QzMyNAchjrku5gzrUY8gl3tRP_k9Shj4=.dd3b406a-3ec5-48e5-8cac-7fc22a772bb4@github.com>
 <VfJlIx4CngZvP7aRkEpqVonWy_EydH67TiZqCV6WsiE=.024ebe71-9e1d-4cc1-9c36-294bcac6b5c6@github.com>
Message-ID: <OhLcyLlSszGAn1VACVOZcssNYCwgr-IXz5zOeAfkzzQ=.9193e46c-5b85-4cd5-b5d2-ea8cd0c13e6c@github.com>

On Wed, 24 Jan 2024 17:22:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This patch tries to fix the invalid test group definition of lib-test.
>> Please review.
>> Thanks.
>
> Ooof. I wonder how that happened. This would not show up before we try to run the actual libtest tests. What is extra wild is that GHA reports green, even though the logs say that TEST.groups is incorrect! I am going to go and fix that...
> 
> The fix looks good and trivial. Thanks for catching it!

Thanks @shipilev .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17558#issuecomment-1909072634

From naoto at openjdk.org  Wed Jan 24 23:24:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 Jan 2024 23:24:35 GMT
Subject: RFR: 8324657: Intermittent OOME on exception message create
In-Reply-To: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
References: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
Message-ID: <RyQ-3Ui3Plj6UHP82d-HSEnYY57kZ7_kktCox_CLIqk=.052192df-1b4f-4f73-8571-8c616f73266d@github.com>

On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
> Explicit use of String.concat() call can improve exception handling.
> 
> Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17522#pullrequestreview-1842551871

From abimpoudis at openjdk.org  Wed Jan 24 23:25:00 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:25:00 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v48]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <c6hsnKQnLHTrtZGJfWm9k2Nkh05OoYZkNRHPuQgKd1Y=.41b85922-d59b-4726-be74-cc9e70d9df6d@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:

  Simplify checkUnconditionallyExact

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/4e5ac772..4ed60e9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=46-47

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 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  Wed Jan 24 23:25:03 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:25:03 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v47]
In-Reply-To: <IgYYtX0n0ZeKB0Bw-bGdMnnbttKgWgCFPCmvYCr5rjs=.bee7a753-1579-4962-b226-43465c062313@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <l4HLJUwtYx4lZzrgw-zcVcrNGTAdgNKmqmYdHbBarv0=.9721e1c9-5ba9-459a-b002-ea714287021a@github.com>
 <IgYYtX0n0ZeKB0Bw-bGdMnnbttKgWgCFPCmvYCr5rjs=.bee7a753-1579-4962-b226-43465c062313@github.com>
Message-ID: <OxYJA95lrHGtxuvOz6hy0yN2bu_rgIWenIQhCrKElzU=.4c8b729d-10ca-477e-a900-cfca8b7f829a@github.com>

On Wed, 24 Jan 2024 21:47:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce ExactnessConversionsSupportTest
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5045:
> 
>> 5043:         }
>> 5044: 
>> 5045:         if (target.isPrimitive()) {
> 
> nit: maybe now a ternary expression can be used

Done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465656376

From jiefu at openjdk.org  Wed Jan 24 23:28:33 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 24 Jan 2024 23:28:33 GMT
Subject: Integrated: 8324647: Invalid test group of lib-test after JDK-8323515
In-Reply-To: <lqoo9p51wj_QzMyNAchjrku5gzrUY8gl3tRP_k9Shj4=.dd3b406a-3ec5-48e5-8cac-7fc22a772bb4@github.com>
References: <lqoo9p51wj_QzMyNAchjrku5gzrUY8gl3tRP_k9Shj4=.dd3b406a-3ec5-48e5-8cac-7fc22a772bb4@github.com>
Message-ID: <nuOzeudzO03T3vyHGdmpwOIOJRPXwYu3DitbYkiprEk=.657019d0-98cd-4ab0-9a15-fe4a24236e81@github.com>

On Wed, 24 Jan 2024 15:20:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> This patch tries to fix the invalid test group definition of lib-test.
> Please review.
> Thanks.

This pull request has now been integrated.

Changeset: 2d5cb972
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d5cb97288f7bf5acaa24632118d6a7a6a53c93e
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8324647: Invalid test group of lib-test after JDK-8323515

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/jdk/pull/17558

From abimpoudis at openjdk.org  Wed Jan 24 23:42:48 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:42:48 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v49]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <ZrgtiMAuOD7pPLWVhozHqBjcHkEzvZKjoczIt6unI2g=.8b62e4f2-95ef-457b-950b-42bf7e274de2@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 redundant clone

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/4ed60e9d..80cfc06c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=47-48

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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  Wed Jan 24 23:42:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:42:51 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
Message-ID: <G6TV0yUHitXPGovPRrI6OLE1Wm0qBNNbrnEEkrbBF2o=.b58d90dc-be70-4187-96ed-fe4e33f28abe@github.com>

On Wed, 24 Jan 2024 17:15:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 168:
> 
>> 166:         requireNonNull(labels);
>> 167: 
>> 168:         labels = labels.clone();
> 
> just curious, why do we need to clone this array?

No need. Remainings of a previous approach. Thanks for spotting

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1465672119

From jlu at openjdk.org  Wed Jan 24 23:45:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jan 2024 23:45:33 GMT
Subject: Integrated: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
In-Reply-To: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
References: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
Message-ID: <FEWpbcy_nsG1NtUH_W_stTWxL_SVstXZcTRBqrfyRBk=.387e145d-e8f0-4e84-b76b-557e9d2ea9d8@github.com>

On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.
> 
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.
> 
> Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.
> 
> Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

This pull request has now been integrated.

Changeset: 3d32c460
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d32c460eb60aa95f27c96bbefdf784f6a7663f7
Stats:     46 lines in 1 file changed: 17 ins; 22 del; 7 mod

6503196: API doc for DecimalFormat::getMaximumIntegerDigits is unclear

Reviewed-by: naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/17541

From abimpoudis at openjdk.org  Wed Jan 24 23:50:51 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 24 Jan 2024 23:50:51 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@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:

  Update year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/80cfc06c..2af70ba2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=48-49

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 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  Wed Jan 24 23:56:27 2024
From: duke at openjdk.org (jmehrens)
Date: Wed, 24 Jan 2024 23:56:27 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <lJGdahlhaU7Ycu_l2pfPCa3-7jsNvm-MXp6Jn0BPWAA=.c5b8e89e-2c64-48d7-b7e5-a17f8fa9f58c@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <3CzOoMtSu0zffIIiUaz1PQFJLVN_pdeRHKpRAqDMnn8=.c0eb6f8f-e5ac-4030-9021-608488933a30@github.com>
 <AzY4635e1Mr3o5yhvRGWWpEnMVUoNW1gIp634fT_hKE=.e97f8805-1117-4f54-9bc2-4cd33e69423d@github.com>
 <lJGdahlhaU7Ycu_l2pfPCa3-7jsNvm-MXp6Jn0BPWAA=.c5b8e89e-2c64-48d7-b7e5-a17f8fa9f58c@github.com>
Message-ID: <cDTYF1PnURcDDFfS4bQW-3LyxDC_hWppqzqCIH05jrE=.42493e5c-569e-4cff-9cfe-4847c79cd454@github.com>

On Wed, 24 Jan 2024 21:53:51 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>...then suggest we should change the Map::size() api to return a long...

For any Map/Collection you can fetch the Spliterator and use estimateSize or getExactSizeIfKnown as both return size as a long.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1909116636

From serb at openjdk.org  Thu Jan 25 00:20:29 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Jan 2024 00:20:29 GMT
Subject: RFR: 8324657: Intermittent OOME on exception message create
In-Reply-To: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
References: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
Message-ID: <CsFObLPKNjOJD4c12deVEMxMCVPKz5wCDvR8Izbv0EY=.d99201cb-076b-4491-a9ac-be835a3c598d@github.com>

On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
> Explicit use of String.concat() call can improve exception handling.
> 
> Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

src/java.base/share/classes/java/io/ObjectInputStream.java line 2016:

> 2014:     // Generate an InvalidObjectException for an OutOfMemoryError
> 2015:     // Use String.concat() to avoid string formatting invoke dynamic
> 2016:     private static InvalidObjectException genInvalidObjectException(OutOfMemoryError oome, String[] ifaces) {

Isn't this new line is too long? It seems most of the file uses 80 chars per line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17522#discussion_r1465700346

From duke at openjdk.org  Thu Jan 25 00:29:40 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 25 Jan 2024 00:29:40 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v3]
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <MCJHjZaXcxTIozJR7q_U6bBEZmfOIw_sn-UEiarIrow=.86c09b91-e743-43e7-9066-da6b4bef7eb4@github.com>

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
> 
> ---
> 
> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
> 
> Before change:
> 
> 
> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       8768892.941            B/op
> HashMapBench.putAllSameKeys:gc.count               100000  LINKED_HASH_MAP  100000  avgt               ? 0          counts
> 
> 
> After change:
> 
> 
> Benchmark                                       (addSize)        (mapType)...

Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:

  Use max of both sizes and other maps size in case of overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17544/files
  - new: https://git.openjdk.org/jdk/pull/17544/files/a74c10da..4ecc08a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544

PR: https://git.openjdk.org/jdk/pull/17544

From duke at openjdk.org  Thu Jan 25 00:29:41 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 25 Jan 2024 00:29:41 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes
In-Reply-To: <cDTYF1PnURcDDFfS4bQW-3LyxDC_hWppqzqCIH05jrE=.42493e5c-569e-4cff-9cfe-4847c79cd454@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <3CzOoMtSu0zffIIiUaz1PQFJLVN_pdeRHKpRAqDMnn8=.c0eb6f8f-e5ac-4030-9021-608488933a30@github.com>
 <AzY4635e1Mr3o5yhvRGWWpEnMVUoNW1gIp634fT_hKE=.e97f8805-1117-4f54-9bc2-4cd33e69423d@github.com>
 <lJGdahlhaU7Ycu_l2pfPCa3-7jsNvm-MXp6Jn0BPWAA=.c5b8e89e-2c64-48d7-b7e5-a17f8fa9f58c@github.com>
 <cDTYF1PnURcDDFfS4bQW-3LyxDC_hWppqzqCIH05jrE=.42493e5c-569e-4cff-9cfe-4847c79cd454@github.com>
Message-ID: <ZgNynSaeAr5Trs00YK7fFECichLwKm4GU-hyGa2vu9o=.b22428ba-66eb-45dd-9335-5f84ecfc0a6c@github.com>

On Wed, 24 Jan 2024 23:53:34 GMT, jmehrens <duke at openjdk.org> wrote:

> For any Map/Collection you can fetch the Spliterator and use estimateSize or getExactSizeIfKnown as both return size as a long.

Based on the code, I think this will just return the original size. It would be the same as casting `(long) size()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1909145170

From duke at openjdk.org  Thu Jan 25 00:29:43 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 25 Jan 2024 00:29:43 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v2]
In-Reply-To: <Jpz5JYd50nXkveOqi6oX7WmH7Qtdacp-IeD_qpRXifw=.01a621a3-b81b-40b8-a3f2-8bdaf1a83ae6@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <Jpz5JYd50nXkveOqi6oX7WmH7Qtdacp-IeD_qpRXifw=.01a621a3-b81b-40b8-a3f2-8bdaf1a83ae6@github.com>
Message-ID: <qp37aZyroGWGdVc9EwayM-0tnH4wu4wk1ApixcJz1P8=.be6d278d-1d78-47d4-84db-3f78b3ea2745@github.com>

On Wed, 24 Jan 2024 20:40:36 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       8768892.941            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000  LINKED_HASH_MAP  100000  avgt               ? 0          counts
>> 
>> 
>> Af...
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark with all duplicate keys

I added a commit to instead compute `max(size() + m.size(), size()`. Its not ideal to use a long here, because we can get stuck in the while loop. The threshold is an int, so if `s` is a long, it will always be bigger than the threshold.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1909146483

From qamai at openjdk.org  Thu Jan 25 03:13:27 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 25 Jan 2024 03:13:27 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
 <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
Message-ID: <t4fAHTZoib8bQzBhFdtGltKs8VPC3B58QiI_uOkhzGw=.c5020a58-e525-45f9-a597-522945206447@github.com>

On Wed, 24 Jan 2024 18:56:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Naive question: the right way to use this would be almost invariably be like this:
>>> 
>>> ```
>>> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>>>     // fast-path
>>> }
>>> // slow path
>>> ```
>>> 
>>> Right? Then the expectation is that during interpreter and C1, `isCompileConstant` always returns false, so we just never take the fast path (but we probably still pay for the branch, right?). And, when we get to C2 and this method is inlined, at this point we know that either `foo` is constant or not. If it is constant we can check other conditions on foo (which presumably is cheap because `foo` is constant) and maybe take the fast-path. In both cases, there's no branch in the generated code because we know "statically" when inlining if `foo` has the right shape or not. Correct?
>> 
>> P.S. if this is correct, please consider adding something along those lines in the javadoc of `isCompileConstant`; as it stands it is a bit obscure to understand how this thing might be used, and what are the common pitfalls to avoid when using it.
>
>> Naive question: the right way to use this would be almost invariably be like this:
>> 
>> ```
>> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>>     // fast-path
>> }
>> // slow path
>> ```
>> 
>> Right? 
> 
> Yes, I think so.
> 
>> Then the expectation is that during interpreter and C1, `isCompileConstant` always returns false, so we just never take the fast path (but we probably still pay for the branch, right?). 
> 
> Yes, I think so. For C1, we would still prune the "dead" path, because C1 is able to know that `if (false)` is never taken. We do pay with the branch and the method call in interpreter. (There are ways to special-case these intrinsics for interpreter too, if we choose to care.)
> 
>> And, when we get to C2 and this method is inlined, at this point we know that either `foo` is constant or not. If it is constant we can check other conditions on foo (which presumably is cheap because `foo` is constant) and maybe take the fast-path. In both cases, there's no branch in the generated code because we know "statically" when inlining if `foo` has the right shape or not. Correct?
> 
> Yes. I think the major use would be using `constexpr`-like code on "const" path, so that the entire code constant-folds completely, _or_ just compiles to branch-less "generic" version. In [my experiments](https://github.com/openjdk/jdk/pull/17527#issuecomment-1906379544) with `Integer.toString` that certainly happens. But that is not a requirement, and we could probably still reap some benefits from partial constant folds; but at that point we would need to prove that a "partially const" path is better than generic "non-const" path under the same conditions.
> 
> I agree it would be convenient to put some examples in javadoc. @merykitty, I can help you with that, if you want.

@shipilev I can come up with 2 examples that are pretty generic:

    void checkIndex(int index, int length) {
        boolean indexPositive = index >= 0;
        if (ConstantSupport.isCompileConstant(indexPositive) && indexPositive) {
            if (index >= length) {
                throw;
            }
            return;
        }
        if (length < 0 || Integer.compareUnsigned(index, length) >= 0) {
            throw;
        }
    }

    bool equals(Point p1, Point p2) {
        idEqual = p1 == p2;
        if (ConstantSupport.isCompileConstant(idEqual) && idEqual) {
            return true;
        }
        return p1.x == p2.x && p1.y == p2.y;
    }

@mcimadamore Yes I believe your expectations are correct. Pitfalls may vary case-by-case, but I just realised that since we do not have profile information in the fast path, the compiler may be less willingly to inline the callees here. While it has not been an issue, a solution I can think of is to have something like `ConstantSupport::evaluate` in which the compiler will try to inline infinitely expecting constant-folding similar to how a `constexpr` variable behaves in C++ (and maybe bail-out compilation if the final result is not a constant, too).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1909272480

From jbhateja at openjdk.org  Thu Jan 25 03:14:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 Jan 2024 03:14:31 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v9]
In-Reply-To: <xdwiUCwY2SrWSC9ZDw7hWycUSPVNLCqKXBK2uYpNd8o=.e73e775a-63f9-405f-b730-73d4b5c42568@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>
 <xdwiUCwY2SrWSC9ZDw7hWycUSPVNLCqKXBK2uYpNd8o=.e73e775a-63f9-405f-b730-73d4b5c42568@github.com>
Message-ID: <LVqL-ucEBJWeo-rBRRPY_FxGxxLQ5qLayUNyxhIz-0M=.6997f068-9211-4cee-a28c-062fcbe13312@github.com>

On Tue, 23 Jan 2024 15:20:47 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8322768
>>  - Modifying comments.
>>  - Review comments resolution
>>  - Modified code comment for clarity.
>>  - Space fixup
>>  - Using emulated variable blend E-Core optimized instruction.
>>  - Review suggestions incorporated.
>>  - Review comments resolutions.
>>  - Updating copyright year of modified files.
>>  - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.
>
> Ok, I'll just run the testing again, and then I will approve this :)

Hi @eme64 , let us know test results. 

Best Regards

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17261#issuecomment-1909272731

From dholmes at openjdk.org  Thu Jan 25 05:08:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Jan 2024 05:08:26 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <-msFouQp2kpWPf6LTKgbDAeLPUkfET6wVesLbAz-6T4=.54ca377c-2e49-4229-a060-daa34485eead@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
 <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>
 <9iDFu8I4w_i1Uso5q7oEi0Le1JvgDNgNyuSZlmKQiuE=.5739d448-fc73-4bcf-bec8-26b3a1b75d21@github.com>
 <WxiAGRmZe3zH9xWJHmrwz20Q_nrbHkLG3CU6624u7nY=.2cd1b7d0-2aaa-4a30-92a0-7027d500c0ed@github.com>
 <-msFouQp2kpWPf6LTKgbDAeLPUkfET6wVesLbAz-6T4=.54ca377c-2e49-4229-a060-daa34485eead@github.com>
Message-ID: <bvM4JToLRGnJg-ycNXH4SL6-icVr2LTXIzGbKcM1Rf0=.32cd4083-5655-418b-b5cc-8ace67c8b34d@github.com>

On Wed, 24 Jan 2024 19:37:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> It is still weird to talk about expressions at this level. We really check if the value is constant, like the method name suggests now. Yes, this implicitly tests that the expression that produced that value is fully constant-folded. But that's a detail that we do not need to capture here. Let's rename `expr` -> `val`, and tighten up the javadoc for the method to mention we only test the constness of the final value.
>
> I agree. All values are produced by evaluating expressions. In this case we want to query whether a value produced by the compiler evaluating its expression is a constant value (inputs to the expression are constants and the expression had no material side-effects). Meaning if the method returns true then we could use that knowledge in subsequent expressions that may also produce constants or some specific behavior.

> the method compilation has the expression in its original form

So the JIT analyses the bytecode used to place the result on the call stack, before the call, and from that determines if the expression were a constant? This kind of self-analysis is not something I was aware of.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1465846860

From dholmes at openjdk.org  Thu Jan 25 05:45:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Jan 2024 05:45:27 GMT
Subject: RFR: JDK-8324598: use mem_unit when working with sysinfo memory
 and swap related information
In-Reply-To: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
References: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
Message-ID: <D73bGx4KvoZcCkgh0t4EA6M8VSU2tuDqxCAegFEvv4k=.508864b5-904a-4e39-ae6f-126c6405f9fe@github.com>

On Wed, 24 Jan 2024 10:07:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
> "In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."
> 
> This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.

Looks fine.

Minor nit with lack of parentheses.

Thanks

src/hotspot/os/linux/os_linux.cpp line 420:

> 418:   struct sysinfo si;
> 419:   sysinfo(&si);
> 420:   return (julong)si.totalswap * si.mem_unit;

Suggestion: `(julong)(si.totalswap * si.mem_unit);

src/java.base/linux/native/libjava/CgroupMetrics.c line 57:

> 55:          return 0; // syinfo failed, treat as no swap
> 56:     }
> 57:     return (jlong)si.totalswap * si.mem_unit;

Suggestion: `(julong)(si.totalswap * si.mem_unit);

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17550#pullrequestreview-1842877781
PR Review Comment: https://git.openjdk.org/jdk/pull/17550#discussion_r1465868336
PR Review Comment: https://git.openjdk.org/jdk/pull/17550#discussion_r1465868493

From duke at openjdk.org  Thu Jan 25 07:13:46 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Thu, 25 Jan 2024 07:13:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
Message-ID: <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>

On Thu, 22 Apr 2021 21:50:45 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
>> 
>>   8200559: Java agents doing instrumentation need a means to define auxiliary classes
>
> Setting '-javaagent' is mainly an operations problem. Many build tools do
> not allow to declare a test dependency this way as the life cycles are not
> laid out for it, the internal repository location might be machine
> dependent, for example, and it's difficult to point to a specific folder
> and file reliably. In this case, I'd say it would be easier to specify a
> parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a
> static value. This would however only work for build tools that initiate a
> new VM for running tests which is not overly attractive for simple builds
> due to the overhead. Of course, Maven, Gradle and similar tools could set
> this parameter by default for their own JVM, that part is likely
> overcomeable but it will certainly create confusion about how to run
> libraries that are omnipresent today and make the JVM ecosystem less
> approachable.
> 
> What bothers me more is the tooling perspective for non-self-attached
> agents. For example, Aaeron offers a Java agent that adds plenty of debug
> logging to relevant lines of code. This affects method size and so forth,
> with Aaeron as a high-performance tool for banking and finance which is
> written very consciously with regards to the JIT, adding it directly was
> not feasible. Normally this logging is therefore thrown into a VM in
> retrospect, once an application starts failing and is already taken off the
> load balancer. For such a post-mortem, it would be rather annoying to
> realize that a JVM cannot be attached to with full capabilities if you
> forgot to set some flag. And often you did of course not consider the VM
> instance to fail, sometimes it takes months to get a JVM into this buggy
> state. This would be fairly inconvenient to face.
> 
> Therefore, I really hope that the dynamic attach from 'outside' the VM will
> survive without imposing limits and that rather the self-attachment problem
> will be targeted as such. When I mention a 'jdk.test' module in the Mockito
> context, I am also rather hoping to improve performance compared to
> convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that
> you still need to start a new VM etc. Since Java 9, running single tests
> with Mockito has for example become much slower compared to Java 8. Despite
> the startup performance improvements in the JVM. If one could avoid the
> location-bound '-javaagent:...', but get the Instrumentation instance
> directly, I think this would render a real performance improvement in
> actual execution scenarios.
> 
> Am Mi., 21. Apr. 2...

@raphw and everyone else, I apologise for commenting on an auto-closed issue, but I have no other way of contacting anyone, because neither do I have an account to comment on [JDK-8200559](https://bugs.openjdk.org/browse/JDK-8200559) nor am I a member in any other of the JDK development or "JVM rock star" circles for good reason: I simply have a very limited understanding of the topic at hand.

I am, however, the current maintainer and project lead of Eclipse AspectJ, and since JDK 16 the weaving agent requires `--add-opens java.base/java.lang=ALL-UNNAMED` along with `-javaagent:/path/to/aspectjweaver.jar` for the reason my predecessor Andy Clement has explained in [AspectJ bug 546305](https://bugs.eclipse.org/bugs/show_bug.cgi?id=546305), which is also linked to JDK-8200559. @mlchung was also involved in the discussion there.

Here, there has been a lot of discussion about Byte Buddy and Mockito. For AspectJ, which is widely used in the industry, not just in Spring but also in countless other productive contexts, there still is no solution to the problem that we need to instrument a target class to call an auxiliary class (generated by the agent) that does not have a Lookup object on the target class to begin with. The target class is still being transformed, i.e. not loaded yet, and hence we cannot look it up.

Is this case being considered? Can any of you advise me how to solve that problem? I am open for advice and hands-on chat, desktop sharing or audio/video call sessions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1909444615

From roland at openjdk.org  Thu Jan 25 07:44:28 2024
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 25 Jan 2024 07:44:28 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
 <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
Message-ID: <zbsXRUIds6SIhWkbcbhrworYyO3IM9zsH4LNNlXsaW8=.0507c3ae-68da-4411-bcf0-8a262eb451c3@github.com>

On Wed, 24 Jan 2024 18:56:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Naive question: the right way to use this would be almost invariably be like this:
> > ```
> > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
> >     // fast-path
> > }
> > // slow path
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Right?
> 
> Yes, I think so.

But then whatever is in the fast path and `fooHasCertainStaticProperties` are never profiled because never executed by the interpreter or c1. So `fooHasCertainStaticProperties` will likely not be inlined and c2 will do a poor (or rather not as good as you'd like) job of compiling whatever is in the fast path.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1909531426

From goetz at openjdk.org  Thu Jan 25 09:06:32 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Thu, 25 Jan 2024 09:06:32 GMT
Subject: [jdk22] Integrated: 8319128: sun/security/pkcs11 tests fail on OL 7.9
 aarch64
In-Reply-To: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
References: <7VSx_e9vczEZR5LCmjIA7tHXvPQ4_2OqTuVSvvu5oOk=.5a3a8cd0-e836-4b6f-b09e-d3effd0d6e1f@github.com>
Message-ID: <cCr1ABcat9FVypdMEAYj79IsxCO3DCbUAXkfYXlZqbg=.9fc077bb-ec9f-4e1a-bcf1-1bc8a695f61b@github.com>

On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this to fix this issue in 22. We see it failing there in our CI.

This pull request has now been integrated.

Changeset: 57bc96e5
Author:    Goetz Lindenmaier <goetz at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/57bc96e5cdc6b30eb5c6a3aeece2341dccc75e97
Stats:     45 lines in 6 files changed: 36 ins; 4 del; 5 mod

8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

Reviewed-by: lucy
Backport-of: c2e77e2f17b624e750dea8fd51bbfde99596690e

-------------

PR: https://git.openjdk.org/jdk22/pull/95

From mbaesken at openjdk.org  Thu Jan 25 09:15:38 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 09:15:38 GMT
Subject: RFR: JDK-8324598: use mem_unit when working with sysinfo memory
 and swap related information [v2]
In-Reply-To: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
References: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
Message-ID: <B3tEJLZsS9Hb1Pi5CJ5TfEhVSoaGD8f3Ard3MeAjpUw=.e0324cec-13ab-4274-9996-13c68ac8034e@github.com>

> According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
> "In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."
> 
> This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  add parentheses

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17550/files
  - new: https://git.openjdk.org/jdk/pull/17550/files/c46b804f..77b2d44e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17550&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17550&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17550/head:pull/17550

PR: https://git.openjdk.org/jdk/pull/17550

From mbaesken at openjdk.org  Thu Jan 25 09:15:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 09:15:40 GMT
Subject: RFR: JDK-8324598: use mem_unit when working with sysinfo memory
 and swap related information
In-Reply-To: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
References: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
Message-ID: <UakwjgWIXS3ORKUjHqPLzyrG9VRBdRTyKSQzJ87Ut70=.a1c27fd2-127e-4392-bedf-74f04ed9294a@github.com>

On Wed, 24 Jan 2024 10:07:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
> "In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."
> 
> This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.

Thanks for the review! I followed your suggestions regarding parenthesis.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17550#issuecomment-1909712920

From epeter at openjdk.org  Thu Jan 25 09:18:36 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 25 Jan 2024 09:18:36 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v9]
In-Reply-To: <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>
Message-ID: <mL2j2s4dKxTHo5zXAb-G8hLHVDlBdXdg8utJeHJzKPM=.b03b2088-1fd4-4b9c-a0b2-2b4c4c818fc2@github.com>

On Tue, 23 Jan 2024 11:56:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
>> These are very frequently used APIs in columnar database filter operation.
>> 
>> Implementation uses a lookup table to record permute indices. Table index is computed using
>> mask argument of compress/expand operation.
>> 
>> Following are the performance number of JMH micro included with the patch.
>> 
>> 
>> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
>> 
>> Baseline:
>> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
>> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
>> 
>> Withopt:
>> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
>> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
>> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
>> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
>> ColumnFilterBenchmark.filterIntColumn       2047  thrpt  ...
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8322768
>  - Modifying comments.
>  - Review comments resolution
>  - Modified code comment for clarity.
>  - Space fixup
>  - Using emulated variable blend E-Core optimized instruction.
>  - Review suggestions incorporated.
>  - Review comments resolutions.
>  - Updating copyright year of modified files.
>  - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.

Testing passed, looks good now :)
Nice progress, the code now is simpler and much more understandable!

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17261#pullrequestreview-1843198049

From shade at openjdk.org  Thu Jan 25 09:30:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Jan 2024 09:30:28 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <-quimoVBzziosvz8NKyrp0fop7T9ZRDg4SJo1wif6aw=.77948f6f-0728-4e57-ae98-5c5472f435ee@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
 <-quimoVBzziosvz8NKyrp0fop7T9ZRDg4SJo1wif6aw=.77948f6f-0728-4e57-ae98-5c5472f435ee@github.com>
Message-ID: <sHWm6ltK5yYizmHIxLWr0WOFW6XUJs0fo_hD7YlfwbQ=.bb4316d5-c0b7-4b4b-9126-98b1c5f94d1a@github.com>

On Wed, 24 Jan 2024 21:28:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
>> 
>> I provisionally call this flag `external-dep`, but I am open for other suggestions.
>> 
>> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
>> 
>> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
>> 
>> Additional testing:
>>  - [x] `make test TEST=applications/` fails
>>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests
>
> Marked as reviewed by lmesnik (Reviewer).

@lmesnik, you good with the keyword name?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1909740587

From mcimadamore at openjdk.org  Thu Jan 25 10:00:47 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:00:47 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
Message-ID: <C0ybRaPJXeBL4HC7DoQLeskmohS24VwMb1sevpassZs=.95aa463b-e58f-42a6-b729-fbfe845d6e3d@github.com>

On Wed, 24 Jan 2024 23:50:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Update year

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 148:

> 146:      * @throws NullPointerException if any argument is {@code null}
> 147:      * @throws IllegalArgumentException if any element in the labels array is null, if the
> 148:      * invocation type is not a method type of first parameter of a reference type,

One thing we did often in the FFM API was to break up long `@throws` and split them into two or three `@throws` (javadoc allows the same exception to appear multiple times). Not saying you have to change this, just a possible suggestion (as I didn't know this!)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466119276

From adinn at openjdk.org  Thu Jan 25 10:06:46 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 25 Jan 2024 10:06:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
Message-ID: <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>

On Thu, 25 Jan 2024 06:39:56 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

>> Setting '-javaagent' is mainly an operations problem. Many build tools do
>> not allow to declare a test dependency this way as the life cycles are not
>> laid out for it, the internal repository location might be machine
>> dependent, for example, and it's difficult to point to a specific folder
>> and file reliably. In this case, I'd say it would be easier to specify a
>> parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a
>> static value. This would however only work for build tools that initiate a
>> new VM for running tests which is not overly attractive for simple builds
>> due to the overhead. Of course, Maven, Gradle and similar tools could set
>> this parameter by default for their own JVM, that part is likely
>> overcomeable but it will certainly create confusion about how to run
>> libraries that are omnipresent today and make the JVM ecosystem less
>> approachable.
>> 
>> What bothers me more is the tooling perspective for non-self-attached
>> agents. For example, Aaeron offers a Java agent that adds plenty of debug
>> logging to relevant lines of code. This affects method size and so forth,
>> with Aaeron as a high-performance tool for banking and finance which is
>> written very consciously with regards to the JIT, adding it directly was
>> not feasible. Normally this logging is therefore thrown into a VM in
>> retrospect, once an application starts failing and is already taken off the
>> load balancer. For such a post-mortem, it would be rather annoying to
>> realize that a JVM cannot be attached to with full capabilities if you
>> forgot to set some flag. And often you did of course not consider the VM
>> instance to fail, sometimes it takes months to get a JVM into this buggy
>> state. This would be fairly inconvenient to face.
>> 
>> Therefore, I really hope that the dynamic attach from 'outside' the VM will
>> survive without imposing limits and that rather the self-attachment problem
>> will be targeted as such. When I mention a 'jdk.test' module in the Mockito
>> context, I am also rather hoping to improve performance compared to
>> convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that
>> you still need to start a new VM etc. Since Java 9, running single tests
>> with Mockito has for example become much slower compared to Java 8. Despite
>> the startup performance improvements in the JVM. If one could avoid the
>> location-bound '-javaagent:...', but get the Instrumentation instance
>> directly, I think this would render a real ...
>
> @raphw and everyone else, I apologise for commenting on an auto-closed issue, but I have no other way of contacting anyone, because neither do I have an account to comment on [JDK-8200559](https://bugs.openjdk.org/browse/JDK-8200559) nor am I a member in any other of the JDK development or "JVM rock star" circles for good reason: I simply have a very limited understanding of the topic at hand.
> 
> I am, however, the current maintainer and project lead of Eclipse AspectJ, and since JDK 16 the weaving agent requires `--add-opens java.base/java.lang=ALL-UNNAMED` along with `-javaagent:/path/to/aspectjweaver.jar` for the reason my predecessor Andy Clement has explained in [AspectJ bug 546305](https://bugs.eclipse.org/bugs/show_bug.cgi?id=546305), which is also linked to JDK-8200559. @mlchung was also involved in the discussion there.
> 
> Here, there has been a lot of discussion about Byte Buddy and Mockito. For AspectJ, which is widely used in the industry, not just in Spring but also in countless other productive contexts, there still is no solution to the problem that we need to instrument a target class to call an auxiliary class (generated by the agent) that does not have a Lookup object on the target class to begin with. The target class is still being transformed, i.e. not loaded yet, and hence we cannot look it up.
> 
> Is this case being considered? Can any of you advise me how to solve that problem? I am open for advice and hands-on chat, desktop sharing or audio/video call sessions.

@kriegaex I resolved this problem in Byteman by opening up the module of the target class to a module (dynamically) created by Byteman. The Instrumentation instance provided to the agent allows you to perform such an opens operation at runtime rather than on the command line.

Byteman relies on an API provided by this module to create the lookups and hand them back for use in woven code. n.b. although this relies on the module exporting a public API, that API can be secured by requiring callers to pass a non-null Instrumentation instance i.e. to have agent capabilities.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1909801331

From jbhateja at openjdk.org  Thu Jan 25 10:10:50 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 Jan 2024 10:10:50 GMT
Subject: RFR: 8322768: Optimize non-subword vector compress and expand APIs
 for AVX2 target. [v9]
In-Reply-To: <mL2j2s4dKxTHo5zXAb-G8hLHVDlBdXdg8utJeHJzKPM=.b03b2088-1fd4-4b9c-a0b2-2b4c4c818fc2@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
 <8oB-M1TUk9aqQIYOGijNmykLCyM1AUTXLTsgy4r8Wk4=.49c90c06-5f2e-47f0-9ac1-ffd6eb438fa4@github.com>
 <mL2j2s4dKxTHo5zXAb-G8hLHVDlBdXdg8utJeHJzKPM=.b03b2088-1fd4-4b9c-a0b2-2b4c4c818fc2@github.com>
Message-ID: <AiNAvMPuTBr0y0uLRO53xfGyqxRu-jOjb4a29LtSPtA=.fe6cbdda-a054-492a-99e6-d53e54f35516@github.com>

On Thu, 25 Jan 2024 09:15:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8322768
>>  - Modifying comments.
>>  - Review comments resolution
>>  - Modified code comment for clarity.
>>  - Space fixup
>>  - Using emulated variable blend E-Core optimized instruction.
>>  - Review suggestions incorporated.
>>  - Review comments resolutions.
>>  - Updating copyright year of modified files.
>>  - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.
>
> Testing passed, looks good now :)
> Nice progress, the code now is simpler and much more understandable!

Thanks @eme64 and @sviswa7 for your comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17261#issuecomment-1909805107

From jbhateja at openjdk.org  Thu Jan 25 10:10:52 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 Jan 2024 10:10:52 GMT
Subject: Integrated: 8322768: Optimize non-subword vector compress and expand
 APIs for AVX2 target.
In-Reply-To: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
References: <_udOCEVG86x9V_WvYqFTaYnvmXdiZ7LzqxzR-D_ygYs=.db3ed37e-a8fa-413b-83c6-a785aba072ff@github.com>
Message-ID: <12ztWzMqNa9AHlWy7O9fx6YWqZDbEcB7xPkBH0nYD-o=.ff640895-79f8-4a75-b1be-800a410a4c28@github.com>

On Thu, 4 Jan 2024 05:28:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi,
> 
> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only targets.
> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 instruction set.
> These are very frequently used APIs in columnar database filter operation.
> 
> Implementation uses a lookup table to record permute indices. Table index is computed using
> mask argument of compress/expand operation.
> 
> Following are the performance number of JMH micro included with the patch.
> 
> 
> System : Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids)
> 
> Baseline:
> Benchmark                                 (size)   Mode  Cnt    Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  142.767          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   71.436          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   35.992          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  182.151          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2   91.096          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2   44.757          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  184.099          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2   91.981          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096  thrpt    2   45.170          ops/ms
> ColumnFilterBenchmark.filterLongColumn      1024  thrpt    2  148.017          ops/ms
> ColumnFilterBenchmark.filterLongColumn      2047  thrpt    2   73.516          ops/ms
> ColumnFilterBenchmark.filterLongColumn      4096  thrpt    2   36.844          ops/ms
> 
> Withopt:
> Benchmark                                 (size)   Mode  Cnt     Score   Error   Units
> ColumnFilterBenchmark.filterDoubleColumn    1024  thrpt    2  2051.707          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    2047  thrpt    2   914.072          ops/ms
> ColumnFilterBenchmark.filterDoubleColumn    4096  thrpt    2   489.898          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     1024  thrpt    2  5324.195          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     2047  thrpt    2  2587.229          ops/ms
> ColumnFilterBenchmark.filterFloatColumn     4096  thrpt    2  1278.665          ops/ms
> ColumnFilterBenchmark.filterIntColumn       1024  thrpt    2  4149.384          ops/ms
> ColumnFilterBenchmark.filterIntColumn       2047  thrpt    2  1791.170          ops/ms
> ColumnFilterBenchmark.filterIntColumn       4096...

This pull request has now been integrated.

Changeset: 6d36eb78
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d36eb78ad781ecd80d66d1319921a8746820394
Stats:     372 lines in 10 files changed: 354 ins; 8 del; 10 mod

8322768: Optimize non-subword vector compress and expand APIs for AVX2 target.

Reviewed-by: epeter, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/17261

From mcimadamore at openjdk.org  Thu Jan 25 10:15:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:15:45 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>
Message-ID: <QqaM5-VqNW3qNdtaYZ5DtBcbitY79wh6pac7euslO1A=.d5569ffe-207e-4538-945c-db3e67301465@github.com>

On Wed, 24 Jan 2024 15:37:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Enhance Javadoc of ExactConversionsSupport (2)
>>  - Enhance Javadoc of ExactConversionsSupport
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 471:
> 
>> 469:                                     // o instanceof float
>> 470:                                     Label notNumber = cb.newLabel();
>> 471:                                     cb.aload(0);
> 
> we are wiring constants into code generation: `0`, `3` etc, probably those won't change but I would prefer using static final fields or enums, that can be documented and changed easily in the future if needed

Note also that the classfile API supports an higher-level construct to access method parameters, which supports _logical_ indexes (see CodeBuilder::parameterSlot). This would make the indices more robust against changes in types (e.g. int vs. long, where the latter would require two local variable slots)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466139675

From mcimadamore at openjdk.org  Thu Jan 25 10:18:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:18:39 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
Message-ID: <6ca0VuWfm7LeOOW5RZ818DP2zSafC87fdBt3LS2ZxPo=.7d7d6285-63a0-4982-95c3-891a9ff86dd2@github.com>

On Wed, 24 Jan 2024 23:50:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Update year

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 592:

> 590:                                     element.caseLabel() instanceof Double ||
> 591:                                     element.caseLabel() instanceof Boolean)) {
> 592:                             //TODO: should call equals on the constant, not on the selector, check

Looking at the code, it seems like we're already calling equals on the constant? (I assume that's to avoid spurious NPEs?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466143827

From mdoerr at openjdk.org  Thu Jan 25 10:22:27 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 25 Jan 2024 10:22:27 GMT
Subject: RFR: JDK-8324598: use mem_unit when working with sysinfo memory
 and swap related information [v2]
In-Reply-To: <B3tEJLZsS9Hb1Pi5CJ5TfEhVSoaGD8f3Ard3MeAjpUw=.e0324cec-13ab-4274-9996-13c68ac8034e@github.com>
References: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
 <B3tEJLZsS9Hb1Pi5CJ5TfEhVSoaGD8f3Ard3MeAjpUw=.e0324cec-13ab-4274-9996-13c68ac8034e@github.com>
Message-ID: <_kuw0f6oHQFo2-GQFxTnNN727iSzgwIkG_bcMP574Ak=.bde4f2e7-64e8-4de7-87c0-5a264a3223a8@github.com>

On Thu, 25 Jan 2024 09:15:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
>> "In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."
>> 
>> This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add parentheses

I would have preferred the original version, but it's ok either way.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17550#pullrequestreview-1843336972

From mcimadamore at openjdk.org  Thu Jan 25 10:25:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:25:38 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
Message-ID: <EfwyYi-nDkzNYFZ7_NPEQEYbk31wUG63NmDt1NQLyPk=.a47251bc-de34-4fcb-ade0-3ef7b1c0a963@github.com>

On Wed, 24 Jan 2024 23:50:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Update year

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 404:

> 402:      */
> 403:     @SuppressWarnings("removal")
> 404:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {

I think the name "labels" for the array here is unfortunate, because the code generation also contains "labels" which mean really "jump targets". Maybe `constants` or `labelConstants` or `caseConstants` ?

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 517:

> 515:                                 }
> 516:                             } else {
> 517:                                 Optional<ClassDesc> classLabelConstableOpt = classLabel.describeConstable();

One comment (for future work): we have a bunch of constants that are known by the time we generate this code (at runtime). But we're still serializing them into the constant pool, and then deserialize them at runtime, which is needless work. Hidden classes support injection of already resolved constants into the constant pool - see:

https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte%5B%5D,java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)

Basically, the idea is that you can pass the entire `labels` array as a "constant data" which is stored in the constant pool as a pre-resolved constant. You can then load elements from this array using ready-made method handles:

https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/invoke/MethodHandles.html#classDataAt(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class,int)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466151276
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466149901

From mcimadamore at openjdk.org  Thu Jan 25 10:25:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 10:25:40 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
 <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>
Message-ID: <iyult5xESig-et8cFe9IBL3NvwYTF74l2t0DxdxJJjo=.f3815d50-61ca-410a-bc4a-50561ad6a4cd@github.com>

On Wed, 24 Jan 2024 17:30:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 461:
>> 
>>> 459:                                     // Object o = ...
>>> 460:                                     // o instanceof Wrapped(float)
>>> 461:                                     cb.aload(0);
>> 
>> probably just a matter of style so up to you, but I don't like the mixing of low level code generation here with higher level logic. I would prefer to see the code generation be extracted if possible to helper methods and or a separate helper class.
>
> see my other comment above that I think supersedes this one

I see what you mean, that said, I think having some high-level checks driving low-level classfile generation is pretty standard for code generators (e.g. lambda metafactory, invoke bytecode generator, binding specializer). I agree on the fact that the lambda should probably moved onto a separate method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466153248

From mbaesken at openjdk.org  Thu Jan 25 10:38:46 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 10:38:46 GMT
Subject: RFR: JDK-8324598: use mem_unit when working with sysinfo memory
 and swap related information [v2]
In-Reply-To: <B3tEJLZsS9Hb1Pi5CJ5TfEhVSoaGD8f3Ard3MeAjpUw=.e0324cec-13ab-4274-9996-13c68ac8034e@github.com>
References: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
 <B3tEJLZsS9Hb1Pi5CJ5TfEhVSoaGD8f3Ard3MeAjpUw=.e0324cec-13ab-4274-9996-13c68ac8034e@github.com>
Message-ID: <tKvpTUlQv5xgJsZLHVzsoAxnLVkcWjFQMUy4SmPepoE=.948ea641-8ec5-49b8-b974-7f08cecc3c6a@github.com>

On Thu, 25 Jan 2024 09:15:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
>> "In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."
>> 
>> This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add parentheses

Hi Martin, thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17550#issuecomment-1909863447

From mbaesken at openjdk.org  Thu Jan 25 10:38:47 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 10:38:47 GMT
Subject: Integrated: JDK-8324598: use mem_unit when working with sysinfo memory
 and swap related information
In-Reply-To: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
References: <TlAK1yOK_L8zLqfKvXgOq427jVgCbKQ1jCkQdwYu1cM=.59aefb8e-f33c-4e98-8826-d34a8fa3ecca@github.com>
Message-ID: <ky9YQvXT7m90pW1rd9fTL6pxBrt6jQ6tGfWzaKnKeXE=.14d7a877-7576-4a66-9252-3b05bd3bd077@github.com>

On Wed, 24 Jan 2024 10:07:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> According to the sysinfo manpage ( https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap related entries in the struct sysinfo are given as multiples of mem_unit bytes.
> "In the above structure, sizes of the memory and swap fields are given as multiples of mem_unit bytes."
> 
> This is considered in most parts of the OpenJDK codebase when sysinfo is used but not all; should be added where it is missing.

This pull request has now been integrated.

Changeset: 7a798d3c
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a798d3cebea0915f8a73af57333b3488c2091af
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8324598: use mem_unit when working with sysinfo memory and swap related information

Reviewed-by: dholmes, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/17550

From duke at openjdk.org  Thu Jan 25 10:48:38 2024
From: duke at openjdk.org (Mateusz Serafin Gajewski)
Date: Thu, 25 Jan 2024 10:48:38 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v9]
In-Reply-To: <tMpLsgXL-ga7sMfSgt-qTnfZfmsjktlgYaBqfakI7nk=.d47d97a0-497a-4fd7-a56c-b5dec02fdbdb@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <9vvYEZjv8zKpu6I8TyBP2vg9vz9V4fgLjXYKgpom3uA=.fc14a299-145a-429d-bf6c-d382af05f398@github.com>
 <tMpLsgXL-ga7sMfSgt-qTnfZfmsjktlgYaBqfakI7nk=.d47d97a0-497a-4fd7-a56c-b5dec02fdbdb@github.com>
Message-ID: <tmhaGj6YL2qwWbpu_wii0nMc6ofGrpsXC7gCAVFEMsA=.1f1adb32-d210-4749-af82-cb1f7af2faf2@github.com>

On Thu, 14 Dec 2023 03:57:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> 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!

Will this fix be backported to JDK 21? @vicente-romero-oracle

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-1886886575

From jlahoda at openjdk.org  Thu Jan 25 10:54:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 25 Jan 2024 10:54:33 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <QqaM5-VqNW3qNdtaYZ5DtBcbitY79wh6pac7euslO1A=.d5569ffe-207e-4538-945c-db3e67301465@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <98Xa1dqszc0IzREHFRDihwUi8_Y-NZ0i47NP-4pcfGc=.fbff61cf-f0ec-49e2-910f-19baa8c68565@github.com>
 <QqaM5-VqNW3qNdtaYZ5DtBcbitY79wh6pac7euslO1A=.d5569ffe-207e-4538-945c-db3e67301465@github.com>
Message-ID: <OjE1NT7kj8psl6VK7AZW5JxTSmkouZXHAfGmjjfyMHw=.0de46281-f09a-43d3-ab67-4b7ae0dcb396@github.com>

On Thu, 25 Jan 2024 10:12:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 471:
>> 
>>> 469:                                     // o instanceof float
>>> 470:                                     Label notNumber = cb.newLabel();
>>> 471:                                     cb.aload(0);
>> 
>> we are wiring constants into code generation: `0`, `3` etc, probably those won't change but I would prefer using static final fields or enums, that can be documented and changed easily in the future if needed
>
> Note also that the classfile API supports an higher-level construct to access method parameters, which supports _logical_ indexes (see CodeBuilder::parameterSlot). This would make the indices more robust against changes in types (e.g. int vs. long, where the latter would require two local variable slots)

This code is intentionally using low-level primitives, as Classfile API is using pattern matching, and using some higher-level primitives is not possible due to the bootstrap issues. `parameterSlot` would probably work, but it does not seem too significant - we know the parameter types that are send to the method, and it is a static method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466187756

From jlahoda at openjdk.org  Thu Jan 25 10:54:36 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 25 Jan 2024 10:54:36 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <6ca0VuWfm7LeOOW5RZ818DP2zSafC87fdBt3LS2ZxPo=.7d7d6285-63a0-4982-95c3-891a9ff86dd2@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
 <6ca0VuWfm7LeOOW5RZ818DP2zSafC87fdBt3LS2ZxPo=.7d7d6285-63a0-4982-95c3-891a9ff86dd2@github.com>
Message-ID: <TmLA3DxTvecFJxe-oJW-b6U8mSQld1N-lai2Ro8V7I8=.fa8300e4-ab4e-4ee4-ac9b-7eb08a14b0b2@github.com>

On Thu, 25 Jan 2024 10:15:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 592:
> 
>> 590:                                     element.caseLabel() instanceof Double ||
>> 591:                                     element.caseLabel() instanceof Boolean)) {
>> 592:                             //TODO: should call equals on the constant, not on the selector, check
> 
> Looking at the code, it seems like we're already calling equals on the constant? (I assume that's to avoid spurious NPEs?)

The note there was to double-check that for selector `s` and constant `l`, we do something like `Long.valueOf(l).equals(s)`, not `s.equals(Long.valueOf(l))`, as the latter does not have the proper semantics. I believe Angelos is adding a test checking this is (and remains) the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466189962

From abimpoudis at openjdk.org  Thu Jan 25 11:21:12 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:12 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v51]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <T4fnCSJKIVf2HGEHcZHKh_ITj4zqcqOCl6SCuZoxsTI=.42c22163-ef56-4a3b-b2b8-d363f2bb0c28@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:

  Improve readability in SwitchBootstraps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/2af70ba2..13bfc436

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=49-50

  Stats: 347 lines in 2 files changed: 138 ins; 115 del; 94 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  Thu Jan 25 11:21:12 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:12 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <EfwyYi-nDkzNYFZ7_NPEQEYbk31wUG63NmDt1NQLyPk=.a47251bc-de34-4fcb-ade0-3ef7b1c0a963@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
 <EfwyYi-nDkzNYFZ7_NPEQEYbk31wUG63NmDt1NQLyPk=.a47251bc-de34-4fcb-ade0-3ef7b1c0a963@github.com>
Message-ID: <r2eQqGYZ7ZRMQnG92MapCYvl-37bgQSynhoaBf92x20=.8d0a334b-fc78-43b4-943b-94eea36c3d8f@github.com>

On Thu, 25 Jan 2024 10:21:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 404:
> 
>> 402:      */
>> 403:     @SuppressWarnings("removal")
>> 404:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {
> 
> I think the name "labels" for the array here is unfortunate, because the code generation also contains "labels" which mean really "jump targets". Maybe `constants` or `labelConstants` or `caseConstants` ?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466217507

From abimpoudis at openjdk.org  Thu Jan 25 11:21:13 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:13 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v45]
In-Reply-To: <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <PUGdr3ibrziXcj4kggtKg17oSG9Frb_hUak3N8agrvU=.75b9fe84-9808-4edd-857f-52730fee4f35@github.com>
 <PVuBlqlSpde8wkhjcoVh1vNfwdgWX8MitdfFVQkPREk=.fd504240-1dbd-46b2-a03a-d609adf4eccc@github.com>
Message-ID: <VsEc9q9BW94meN_H8Up_whqIrhYdNQ29ZagPSqmRNXk=.9b1f1d90-2a0b-4038-8dd7-eb6ace3a4e69@github.com>

On Wed, 24 Jan 2024 17:29:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant test from checkUnconditionallyExact
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 405:
> 
>> 403:      */
>> 404:     @SuppressWarnings("removal")
>> 405:     private static MethodHandle generateInnerClass(MethodHandles.Lookup caller, Class<?> selectorType, Object[] labels) {
> 
> again a matter of style but it seems to me that the huge lambda inside of this method, starting in line 409, really wants to be a separate helper method. That will probably be a better refactoring as we won't be mixing byte code generation with method handles manipulation.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466217863

From abimpoudis at openjdk.org  Thu Jan 25 11:21:13 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 11:21:13 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v44]
In-Reply-To: <iyult5xESig-et8cFe9IBL3NvwYTF74l2t0DxdxJJjo=.f3815d50-61ca-410a-bc4a-50561ad6a4cd@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <FU25qF2R0Agx7UW1MqslTSyN67mWh05sIrs5Tn_Vwz4=.50c686ed-ee26-4cc8-918a-4c0095ab3aa5@github.com>
 <0g1L6FBda3O8Wz02hDrLEIXzUDdRh4or6H3N-szm5Lg=.e5ec4739-577e-4833-b71d-848c26978d4d@github.com>
 <vG61n0KrAgt0bxRFlnDWvTkF14oKqxgy-dRVKogpcyQ=.cfda282c-c0d8-45cc-a9f0-71c9ba39002d@github.com>
 <iyult5xESig-et8cFe9IBL3NvwYTF74l2t0DxdxJJjo=.f3815d50-61ca-410a-bc4a-50561ad6a4cd@github.com>
Message-ID: <u38zE5Xd_22KarF26kUEZuGeHW3NGQe9yn6qLhfKu34=.1c353819-364b-447a-99ec-7cb56486807d@github.com>

On Thu, 25 Jan 2024 10:22:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> see my other comment above that I think supersedes this one
>
> I see what you mean, that said, I think having some high-level checks driving low-level classfile generation is pretty standard for code generators (e.g. lambda metafactory, invoke bytecode generator, binding specializer). I agree on the fact that the lambda should probably moved onto a separate method.

Done in https://github.com/openjdk/jdk/pull/15638/commits/13bfc43654f23f842ac71c1971de32da209d64d3

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466219133

From winterhalter at openjdk.org  Thu Jan 25 12:18:49 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Thu, 25 Jan 2024 12:18:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.

BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation. This also caters the need to inject utility classes from an agent before any class file transformer is triggered, to maintain a well-defined life-cycle.

Of course I'd prefer if there was a way to resolve a lookup from Instrumentation for a given class loader and for example a package-info class, however rendering the issue that packages might not exist (yet).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1910087337

From mcimadamore at openjdk.org  Thu Jan 25 12:55:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 12:55:36 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <zbsXRUIds6SIhWkbcbhrworYyO3IM9zsH4LNNlXsaW8=.0507c3ae-68da-4411-bcf0-8a262eb451c3@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
 <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
 <zbsXRUIds6SIhWkbcbhrworYyO3IM9zsH4LNNlXsaW8=.0507c3ae-68da-4411-bcf0-8a262eb451c3@github.com>
Message-ID: <JmyZ7tlQuDaMsJbTqA5fuLALW_DeW3lBIMAyA2otXJA=.2059cb31-605b-45e0-8d3f-ee13574472fe@github.com>

On Thu, 25 Jan 2024 07:41:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> > > Naive question: the right way to use this would be almost invariably be like this:
> > > ```
> > > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
> > >     // fast-path
> > > }
> > > // slow path
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Right?
> > 
> > 
> > Yes, I think so.
> 
> But then whatever is in the fast path and `fooHasCertainStaticProperties` are never profiled because never executed by the interpreter or c1. So `fooHasCertainStaticProperties` will likely not be inlined and c2 will do a poor (or rather not as good as you'd like) job of compiling whatever is in the fast path.

I suppose perhaps it is implied that `fooHasCertainStaticProperties` should have `@ForceInline` ? But yes, there seems to be several assumptions in how this logic is supposed to be used, and at the moment, it seems to me more of a footgun than something actually useful (but I admit my ignorance on the subject).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1910140980

From forax at univ-mlv.fr  Thu Jan 25 13:32:06 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 25 Jan 2024 14:32:06 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <SJ0PR10MB5766E5F659E88B93DF91C51AFF712@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1963763428.112168110.1706189526386.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Wednesday, January 24, 2024 2:34:11 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> Presuming that you mean mutating the Gatherer such that its behavior isn't
> stable, the difference (at least to me) is that creating such a mutable
> Gatherer would violate the specification of Gatherer: [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63
> ]

If there is a method characteristics, its spec will also indicates that a flag like STATELESS is only allowed but be used if the state is null. 
Not using STATELESS correctly will be also a violation of the spec. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Tuesday, 23 January 2024 21:04
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Monday, January 22, 2024 10:06:27 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> The flags are in sync with the implementation because the only way to create a
>>> Gatherer if through the factory methods and those factory methods (and only
>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>> user.

>> But I presume this also requires to have a `int characteristics()`-method on the
>> Gatherer interfacewhich means that users who are not using the factory methods
>> will have full possibility of not only returning the flags, but returning any
>> int.

> The current implementation suffers the same kind of issue, it's easy to write a
> mutable Gatherer and change the functions after creation, worst, right in the
> middle of a call to stream.gather(...).

> Perhaps the Gatherer interface should be sealed ? We did not have that option
> during the 1.8 timeframe, when the Collector API was created.

>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>> good citizen and works seemlessly with the other intermediary operations.

>> I can see where you're coming from here, but to me, adding API surface needs to
>> pull its weight.
>> In this case I wasn't convinced that it did, hence we're having this
>> conversation. \uD83D\uDE42

>> Cheers,
>> ?

> regards,
> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Monday, 22 January 2024 19:56
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> Hi R?mi,

>> Hello,

>>> For instance, stateless is neither recessive nor dominant, since the composition
>>> of two stateless operations is only ever stateless if they both are greedy as
>>> well: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>> ]

>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>> the combination is ad-hoc, reflecting the characterristics is enough.

>>> So even if making it represented as ints (more like Spliterator, rather than
>>> Collector) makes things faster, it's still both work to track, propagate, and
>>> also becomes a side-channel that needs to remain in sync with the actual
>>> implementation of the logic.

>> The flags are in sync with the implementation because the only way to create a
>> Gatherer if through the factory methods and those factory methods (and only
>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>> user.

>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>> performance bug/inefficiency in an of itself as it would be faster to do
>>> someCollection.size().

>> The stream implementation has a whole mechanism in place to propagate/preverse
>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>> good citizen and works seemlessly with the other intermediary operations.

>> Cheers,
>> ?

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Monday, 22 January 2024 19:56
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> Hi R?mi,

>> Hello,

>>> For instance, stateless is neither recessive nor dominant, since the composition
>>> of two stateless operations is only ever stateless if they both are greedy as
>>> well: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>> ]

>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>> the combination is ad-hoc, reflecting the characterristics is enough.

>>> So even if making it represented as ints (more like Spliterator, rather than
>>> Collector) makes things faster, it's still both work to track, propagate, and
>>> also becomes a side-channel that needs to remain in sync with the actual
>>> implementation of the logic.

>> The flags are in sync with the implementation because the only way to create a
>> Gatherer if through the factory methods and those factory methods (and only
>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>> user.

>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>> performance bug/inefficiency in an of itself as it would be faster to do
>>> someCollection.size().

>> The stream implementation has a whole mechanism in place to propagate/preverse
>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>> good citizen and works seemlessly with the other intermediary operations.

>>> Cheers,
>>> ?

>> regards,
>> R?mi

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Saturday, 20 January 2024 17:40
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>> <psandoz at openjdk.java.net>
>>>> Sent: Thursday, January 18, 2024 5:14:38 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>>> both gatherers keep it sorted.

>>>> That is unfortunately not the case. That would presume that you can implement
>>>> the composition such that it can preserve all the common flags. Some flags
>>>> could be "dominant" and some "recessive" to use genetics nomenclature.

>>> Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not
>>> the characteristics of the Gatherer which can have the corresponding "dominant"
>>> flag, GREEDY, in this case.
>>> And the same for sequential, the flag should be PARALELIZABLE and not
>>> SEQUENTIAL.

>>> The idea is that the Gatherer characteristics can have the same bit set at the
>>> same position as the stream op flags (as defined by StreamOpFlag).
>>> So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED
>>> is in position 3.
>>> For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit
>>> (using XOR) when we want to extract the stream op flags from the
>>> characteristics

>>> All the factory methods call the generic of() with a combination of
>>> PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY,
>>> KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be
>>> raised).

>>> In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for
>>> our two new states PARALELIZABLE and STATELESS, so no problem here (technically
>>> we can also reuse positions of the Spliterator characteristic given that those
>>> flags are masked before being sent to the GathererOp super constructor).

>>> The way to transform a Gatherer characteristics op to a stream flags op is to
>>> flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags
>>> but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask
>>> to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

>>> public static int toOpFlags ( int characteristics ) {
>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>> STREAM_OP_MASK ;
>>> }

>>> see below for a full script.

>>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>>> and i do not understand how it can make the other operations slower.

>>>> Extra invocations, extra storage, and extra composition overhead is not free.
>>>> Since Stream is one-shot you need to include the construction cost with the
>>>> execution cost. For something like an empty Stream construction cost scan be
>>>> 90+% of the total costs.

>>> If you create a Gatherer, the characteristics is a constant (so the validity
>>> check is removed, it's just a mask and a test) so the result of calling
>>> toOpFlags() is a constant too.

>>> If the factory method is not inlined, the cost is 3 bitwise operations which is
>>> I believe faster than the "instanceof Greedy" used in the current code.

>>>> Cheers,
>>>> ?

>>> regards,
>>> R?mi

>>> ---
>>> public class GathererFlag {
>>> // cut and paste from StreamOpFlag
>>> /**
>>> * The bit pattern for setting/injecting a flag.
>>> */
>>> private static final int SET_BITS = 0b01 ;

>>> /**
>>> * The bit pattern for clearing a flag.
>>> */
>>> private static final int CLEAR_BITS = 0b10 ;

>>> /**
>>> * The bit pattern for preserving a flag.
>>> */
>>> private static final int PRESERVE_BITS = 0b11 ;

>>> private static int position ( int opFlagSet ) {
>>> return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ;
>>> }

>>> private static final int DISTINCT_POSITION = position ( StreamOpFlag .
>>> IS_DISTINCT );
>>> private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED
>>> );
>>> private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED );

>>> private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag .
>>> IS_SHORT_CIRCUIT );
>>> private static final int STATELESS_POSITION = 14 ;
>>> private static final int PARELLIZABLE_POSITION = 15 ;

>>> public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1
>>> );
>>> public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 );
>>> public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 );

>>> public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 );
>>> public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 );
>>> public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 );

>>> private static final int SHORT_CIRCUIT_MASK = SET_BITS << (
>>> SHORT_CIRCUIT_POSITION << 1 );

>>> // no GREEDY here
>>> private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS |
>>> KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ;

>>> private static final int STREAM_OP_MASK =
>>> (( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) |
>>> GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ;

>>> public static String toString ( int characteristics ) {
>>> return Stream . of ( characteristics )
>>> .< String >mapMulti(( f , consumer ) -> {
>>> if (( f & PARELLIZABLE ) == PARELLIZABLE ) {
>>> consumer .accept( "PARELLIZABLE" );
>>> }
>>> if (( f & STATELESS ) == STATELESS ) {
>>> consumer .accept( "STATELESS" );
>>> }
>>> if (( f & GREEDY ) == GREEDY ) {
>>> consumer .accept( "GREEDY" );
>>> }
>>> if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) {
>>> consumer .accept( "KEEP_DISTINCT" );
>>> }
>>> if (( f & KEEP_SORTED ) == KEEP_SORTED ) {
>>> consumer .accept( "KEEP_SORTED" );
>>> }
>>> if (( f & KEEP_SIZED ) == KEEP_SIZED ) {
>>> consumer .accept( "KEEP_SIZED" );
>>> }
>>> })
>>> .collect( Collectors . joining ( ", " ));
>>> }

>>> public static int toOpFlags ( int characteristics ) {
>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>> STREAM_OP_MASK ;
>>> }

>>> public static String toOpFlagsString ( int opFlags ) {
>>> return Arrays . stream ( StreamOpFlag . values ())
>>> .map( op -> {
>>> if ( op .isPreserved( opFlags )) {
>>> return "preserved " + op ;
>>> }
>>> if ( op .isCleared( opFlags )) {
>>> return "cleared " + op ;
>>> }
>>> if ( op .isKnown( opFlags )) {
>>> return "set " + op ;
>>> }
>>> return "?? " + op ;
>>> })
>>> .collect( Collectors . joining ( ", " ));
>>> }

>>> void main () {
>>> var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT |
>>> KEEP_SORTED | KEEP_SIZED ;
>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics )));

>>> var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ;
>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 )));
>>> }
>>> }

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>> Sent: Thursday, 18 January 2024 16:17
>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>> <psandoz at openjdk.java.net>
>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>> propagated

>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>> <psandoz at openjdk.java.net>
>>>>> Sent: Thursday, January 18, 2024 3:36:07 PM
>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>>>>> others will want to be able to have INJECT-flags, and then people might have
>>>>> different opinions w.r.t. the default should be to clear all flags etc.

>>>>> And that's even before one looks at the composition-part of it, what are the
>>>>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>>>>> set of flags always approaches 0)

>>>>> I spent quite a bit of time on this and in the end tracking all this info, and
>>>>> making sure that the flags of implementations correspond to the actual
>>>>> behavior, just ended up costing performance for most streams and introduced an
>>>>> extra dimension to creation and maintenance which I had a hard time justifying.

>>>> It can be a slippery slope if we were designing from the ground up but the
>>>> stream implementation already exists and SORTED, DISTINCT and SIZED are the
>>>> flags that are already tracked by the current implementation.

>>>> Currently only SHORT_CIRCUIT is set (if not greedy),
>>>> see [
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
>>>> |
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
>>>> ]

>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>> both gatherers keep it sorted.

>>>>> Making specific, rare, combinations of operations faster at the expense of
>>>>> making 99% of all others slower is a hard pill for most to swallow.

>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>> and i do not understand how it can make the other operations slower.

>>>>> Cheers,
>>>>> ?

>>>> regards,
>>>> R?mi

>>>>> Viktor Klang
>>>>> Software Architect, Java Platform Group
>>>>> Oracle

>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>> Sent: Thursday, 18 January 2024 10:28
>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>> <psandoz at openjdk.java.net>
>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>> propagated

>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>>>>> <core-libs-dev at openjdk.java.net>
>>>>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>> Hi R?mi,

>>>>>> You can find some of my benches here: [
>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>>>>> |
>>>>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>>>>> ]

>>>>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>>>>> didn't end up worth it when looking at the bench results over a wide array of
>>>>>> stream sizes and number of operations.

>>>>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>>>>> KEEP_DISTINCT and KEEP_SIZED,
>>>>> all of them say that if the stream was sorted/distinct/sized then the stream
>>>>> returned by a call to gather() is still sorted (with the same comparator),
>>>>> distinct or sized.

>>>>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>>>>> windowFixed is KEEP_DISTINCT.

>>>>> [CC Paul, so he can correct me if i'm saying something stupid]

>>>>> Now for the benchmarks, it depends what you want to measure, benchmarking
>>>>> streams is tricky. This is what i know about benchmarking streams.
>>>>> First, the JIT has two ways to profile types at runtime,
>>>>> Either a method takes a function as parameter
>>>>> void map(Function function) {
>>>>> function.apply(...)
>>>>> }
>>>>> and when map is called with a subtype of Function, the JIT will propagate the
>>>>> exact type when map is inlined,
>>>>> Or a method use a field
>>>>> class Op {
>>>>> Function function;

>>>>> void map() {
>>>>> function.apply(...)
>>>>> }
>>>>> }
>>>>> in that case, the VM records the profile of function.apply() and if there are
>>>>> more than two different profiles, the VM declare profile poluttion and do not
>>>>> try to optimize.

>>>>> The Stream implementation tries very hard to use only parameters instead of
>>>>> fields, that's why it does not use classical Iterator that are pull iterator (a
>>>>> filter iterator requires a field) but a Spliterator which is a push iterator,
>>>>> the element is sent as parameter of the consumer.That's also why collect does
>>>>> not use the builder pattern (that accumulate values in fields) but a Collector
>>>>> that publish the functions to be called as parameter.

>>>>> Obvisously, this is more complex than that, a Collector stores the functions in
>>>>> fields so it should not work well but the implementation uses a record that
>>>>> plays well with escape analysis. Escape analysis see the fields of an instance
>>>>> as parameters so the functions of a Collector are correctly propagated (if the
>>>>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>>>>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>>>>> are routinely fully inlined with the intermediate operation of a stream.

>>>>> In your tests, i've not seen comparaisons between an existing method like map()
>>>>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>>>>> where the characteristics KEEP_* have an impact and their equivalent using a
>>>>> Gatherer.

>>>>>> Cheers,
>>>>>> ?

>>>>> regards,
>>>>> R?mi

>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle

>>>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>>>>> <forax at univ-mlv.fr>
>>>>>> Sent: Wednesday, 17 January 2024 16:48
>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>> Subject: Gatherer: spliterator characteristics are not propagated
>>>>>> While doing some benchmarking of the Gatherer API, i've found that the
>>>>>> characteristics of the spliterator was not propagated by the method
>>>>>> Stream.gather() making the stream slower than it should.

>>>>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>>>>> that this intermediate operation keep the size, which is important if the
>>>>>> terminal operation is toList() because if the size is known, toList() will
>>>>>> presize the List and avoid the creation of an intermediary ArrayList.

>>>>>> See [
>>>>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>>>>> |
>>>>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>>>>> ]

>>>>>> I think that adding a way to propagate the spliterator characteristics through a
>>>>>> Gatherer would greatly improve the performance of commons streams (at least all
>>>>>> the ones that end with a call to toList).

>>>>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>>>>> something and if improving the performance is something worth changing the API.

>>>>>> regards,
>>>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240125/339de410/attachment-0001.htm>

From adinn at openjdk.org  Thu Jan 25 13:35:45 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 25 Jan 2024 13:35:45 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
Message-ID: <G-3j-YJ-BW1budiSq44FNc7d7DewmnmczBVySYWq0qo=.e2d7de0e-ad55-451c-b3b4-427baa687489@github.com>

On Thu, 25 Jan 2024 12:16:13 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.

How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null Instrumentation object (a value which any agent ought to keep secret). However, it could just as easily have employed an arbitrary bit length hash key. The key can be used to initialize a module-private static long[] field of an API implementation class generated into the module i.e. the hole can actually be a keyhole in the shape of a key known only to the API client and implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1910230873

From abimpoudis at openjdk.org  Thu Jan 25 13:53:06 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 13:53:06 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v50]
In-Reply-To: <C0ybRaPJXeBL4HC7DoQLeskmohS24VwMb1sevpassZs=.95aa463b-e58f-42a6-b729-fbfe845d6e3d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <UATHl2XslXdwh8Vm4qE3G7_PQEU1VkZPGnbdRxAsIUg=.270a23e2-7cf7-4284-8e50-35779144ee5b@github.com>
 <C0ybRaPJXeBL4HC7DoQLeskmohS24VwMb1sevpassZs=.95aa463b-e58f-42a6-b729-fbfe845d6e3d@github.com>
Message-ID: <MWT9nsMPdVkpHKVyDClitF2L3dJKPMBLUXYPAaUwf9Q=.09d3979e-12a6-4359-9412-ff8850a56227@github.com>

On Thu, 25 Jan 2024 09:57:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 148:
> 
>> 146:      * @throws NullPointerException if any argument is {@code null}
>> 147:      * @throws IllegalArgumentException if any element in the labels array is null, if the
>> 148:      * invocation type is not a method type of first parameter of a reference type,
> 
> One thing we did often in the FFM API was to break up long `@throws` and split them into two or three `@throws` (javadoc allows the same exception to appear multiple times). Not saying you have to change this, just a possible suggestion (as I didn't know this!)

Indeed it looks better:

<img width="566" alt="Screenshot 2024-01-25 at 14 49 07" src="https://github.com/openjdk/jdk/assets/765983/84e6ae34-1e6b-4d36-98de-78f101be2336">

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1466406565

From abimpoudis at openjdk.org  Thu Jan 25 13:53:04 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 13:53:04 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v52]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <aJg0I0EY3tW9XPpzC5F-fKmARuwBY5EQ40Ny2VP8_iM=.a2f969a2-588d-47e1-9a3d-f4659637bd62@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:

  Tidy up Javadoc of IllegalArgumentException in typeSwitch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/13bfc436..b77d2316

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=50-51

  Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 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 forax at univ-mlv.fr  Thu Jan 25 13:57:34 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 25 Jan 2024 14:57:34 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Wednesday, January 24, 2024 2:45:15 PM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> As a (related) side-note, the ability to implement the interface directly has a
> significant benefit to being able to have tighter control on
> efficiency/performance as well as behavior under composition, here are some
> examples: [
> https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113
> |
> https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113
> ]

I've not seen any differences in term of performance: 
MapGathererBenchmark.gatherer_map_sum?????????       avgt??? 5? 546.058 ? 4.224? us/op 
MapGathererBenchmark.gatherer_mapsublcass_sum? avgt??? 5? 546.391 ? 1.508? us/op 
but yes, being able to override andThen() is important. 

> Cheers,
> ?

R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang
> <viktor.klang at oracle.com>
> Sent: Wednesday, 24 January 2024 14:34
> To: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: Re: Gatherer: spliterator characteristics are not propagated
> Presuming that you mean mutating the Gatherer such that its behavior isn't
> stable, the difference (at least to me) is that creating such a mutable
> Gatherer would violate the specification of Gatherer: [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63
> ]

> Cheers,
> ?

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Tuesday, 23 January 2024 21:04
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Monday, January 22, 2024 10:06:27 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> The flags are in sync with the implementation because the only way to create a
>>> Gatherer if through the factory methods and those factory methods (and only
>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>> user.

>> But I presume this also requires to have a `int characteristics()`-method on the
>> Gatherer interfacewhich means that users who are not using the factory methods
>> will have full possibility of not only returning the flags, but returning any
>> int.

> The current implementation suffers the same kind of issue, it's easy to write a
> mutable Gatherer and change the functions after creation, worst, right in the
> middle of a call to stream.gather(...).

> Perhaps the Gatherer interface should be sealed ? We did not have that option
> during the 1.8 timeframe, when the Collector API was created.

>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>> good citizen and works seemlessly with the other intermediary operations.

>> I can see where you're coming from here, but to me, adding API surface needs to
>> pull its weight.
>> In this case I wasn't convinced that it did, hence we're having this
>> conversation. \uD83D\uDE42

>> Cheers,
>> ?

> regards,
> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Monday, 22 January 2024 19:56
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> Hi R?mi,

>> Hello,

>>> For instance, stateless is neither recessive nor dominant, since the composition
>>> of two stateless operations is only ever stateless if they both are greedy as
>>> well: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>> ]

>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>> the combination is ad-hoc, reflecting the characterristics is enough.

>>> So even if making it represented as ints (more like Spliterator, rather than
>>> Collector) makes things faster, it's still both work to track, propagate, and
>>> also becomes a side-channel that needs to remain in sync with the actual
>>> implementation of the logic.

>> The flags are in sync with the implementation because the only way to create a
>> Gatherer if through the factory methods and those factory methods (and only
>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>> user.

>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>> performance bug/inefficiency in an of itself as it would be faster to do
>>> someCollection.size().

>> The stream implementation has a whole mechanism in place to propagate/preverse
>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>> good citizen and works seemlessly with the other intermediary operations.

>> Cheers,
>> ?

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Monday, 22 January 2024 19:56
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> Hi R?mi,

>> Hello,

>>> For instance, stateless is neither recessive nor dominant, since the composition
>>> of two stateless operations is only ever stateless if they both are greedy as
>>> well: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>> ]

>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>> the combination is ad-hoc, reflecting the characterristics is enough.

>>> So even if making it represented as ints (more like Spliterator, rather than
>>> Collector) makes things faster, it's still both work to track, propagate, and
>>> also becomes a side-channel that needs to remain in sync with the actual
>>> implementation of the logic.

>> The flags are in sync with the implementation because the only way to create a
>> Gatherer if through the factory methods and those factory methods (and only
>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>> user.

>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>> performance bug/inefficiency in an of itself as it would be faster to do
>>> someCollection.size().

>> The stream implementation has a whole mechanism in place to propagate/preverse
>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>> good citizen and works seemlessly with the other intermediary operations.

>>> Cheers,
>>> ?

>> regards,
>> R?mi

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Saturday, 20 January 2024 17:40
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>> <psandoz at openjdk.java.net>
>>>> Sent: Thursday, January 18, 2024 5:14:38 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>>> both gatherers keep it sorted.

>>>> That is unfortunately not the case. That would presume that you can implement
>>>> the composition such that it can preserve all the common flags. Some flags
>>>> could be "dominant" and some "recessive" to use genetics nomenclature.

>>> Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not
>>> the characteristics of the Gatherer which can have the corresponding "dominant"
>>> flag, GREEDY, in this case.
>>> And the same for sequential, the flag should be PARALELIZABLE and not
>>> SEQUENTIAL.

>>> The idea is that the Gatherer characteristics can have the same bit set at the
>>> same position as the stream op flags (as defined by StreamOpFlag).
>>> So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED
>>> is in position 3.
>>> For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit
>>> (using XOR) when we want to extract the stream op flags from the
>>> characteristics

>>> All the factory methods call the generic of() with a combination of
>>> PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY,
>>> KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be
>>> raised).

>>> In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for
>>> our two new states PARALELIZABLE and STATELESS, so no problem here (technically
>>> we can also reuse positions of the Spliterator characteristic given that those
>>> flags are masked before being sent to the GathererOp super constructor).

>>> The way to transform a Gatherer characteristics op to a stream flags op is to
>>> flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags
>>> but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask
>>> to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

>>> public static int toOpFlags ( int characteristics ) {
>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>> STREAM_OP_MASK ;
>>> }

>>> see below for a full script.

>>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>>> and i do not understand how it can make the other operations slower.

>>>> Extra invocations, extra storage, and extra composition overhead is not free.
>>>> Since Stream is one-shot you need to include the construction cost with the
>>>> execution cost. For something like an empty Stream construction cost scan be
>>>> 90+% of the total costs.

>>> If you create a Gatherer, the characteristics is a constant (so the validity
>>> check is removed, it's just a mask and a test) so the result of calling
>>> toOpFlags() is a constant too.

>>> If the factory method is not inlined, the cost is 3 bitwise operations which is
>>> I believe faster than the "instanceof Greedy" used in the current code.

>>>> Cheers,
>>>> ?

>>> regards,
>>> R?mi

>>> ---
>>> public class GathererFlag {
>>> // cut and paste from StreamOpFlag
>>> /**
>>> * The bit pattern for setting/injecting a flag.
>>> */
>>> private static final int SET_BITS = 0b01 ;

>>> /**
>>> * The bit pattern for clearing a flag.
>>> */
>>> private static final int CLEAR_BITS = 0b10 ;

>>> /**
>>> * The bit pattern for preserving a flag.
>>> */
>>> private static final int PRESERVE_BITS = 0b11 ;

>>> private static int position ( int opFlagSet ) {
>>> return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ;
>>> }

>>> private static final int DISTINCT_POSITION = position ( StreamOpFlag .
>>> IS_DISTINCT );
>>> private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED
>>> );
>>> private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED );

>>> private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag .
>>> IS_SHORT_CIRCUIT );
>>> private static final int STATELESS_POSITION = 14 ;
>>> private static final int PARELLIZABLE_POSITION = 15 ;

>>> public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1
>>> );
>>> public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 );
>>> public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 );

>>> public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 );
>>> public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 );
>>> public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 );

>>> private static final int SHORT_CIRCUIT_MASK = SET_BITS << (
>>> SHORT_CIRCUIT_POSITION << 1 );

>>> // no GREEDY here
>>> private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS |
>>> KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ;

>>> private static final int STREAM_OP_MASK =
>>> (( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) |
>>> GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ;

>>> public static String toString ( int characteristics ) {
>>> return Stream . of ( characteristics )
>>> .< String >mapMulti(( f , consumer ) -> {
>>> if (( f & PARELLIZABLE ) == PARELLIZABLE ) {
>>> consumer .accept( "PARELLIZABLE" );
>>> }
>>> if (( f & STATELESS ) == STATELESS ) {
>>> consumer .accept( "STATELESS" );
>>> }
>>> if (( f & GREEDY ) == GREEDY ) {
>>> consumer .accept( "GREEDY" );
>>> }
>>> if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) {
>>> consumer .accept( "KEEP_DISTINCT" );
>>> }
>>> if (( f & KEEP_SORTED ) == KEEP_SORTED ) {
>>> consumer .accept( "KEEP_SORTED" );
>>> }
>>> if (( f & KEEP_SIZED ) == KEEP_SIZED ) {
>>> consumer .accept( "KEEP_SIZED" );
>>> }
>>> })
>>> .collect( Collectors . joining ( ", " ));
>>> }

>>> public static int toOpFlags ( int characteristics ) {
>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>> STREAM_OP_MASK ;
>>> }

>>> public static String toOpFlagsString ( int opFlags ) {
>>> return Arrays . stream ( StreamOpFlag . values ())
>>> .map( op -> {
>>> if ( op .isPreserved( opFlags )) {
>>> return "preserved " + op ;
>>> }
>>> if ( op .isCleared( opFlags )) {
>>> return "cleared " + op ;
>>> }
>>> if ( op .isKnown( opFlags )) {
>>> return "set " + op ;
>>> }
>>> return "?? " + op ;
>>> })
>>> .collect( Collectors . joining ( ", " ));
>>> }

>>> void main () {
>>> var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT |
>>> KEEP_SORTED | KEEP_SIZED ;
>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics )));

>>> var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ;
>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 )));
>>> }
>>> }

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>> Sent: Thursday, 18 January 2024 16:17
>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>> <psandoz at openjdk.java.net>
>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>> propagated

>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>> <psandoz at openjdk.java.net>
>>>>> Sent: Thursday, January 18, 2024 3:36:07 PM
>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>>>>> others will want to be able to have INJECT-flags, and then people might have
>>>>> different opinions w.r.t. the default should be to clear all flags etc.

>>>>> And that's even before one looks at the composition-part of it, what are the
>>>>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>>>>> set of flags always approaches 0)

>>>>> I spent quite a bit of time on this and in the end tracking all this info, and
>>>>> making sure that the flags of implementations correspond to the actual
>>>>> behavior, just ended up costing performance for most streams and introduced an
>>>>> extra dimension to creation and maintenance which I had a hard time justifying.

>>>> It can be a slippery slope if we were designing from the ground up but the
>>>> stream implementation already exists and SORTED, DISTINCT and SIZED are the
>>>> flags that are already tracked by the current implementation.

>>>> Currently only SHORT_CIRCUIT is set (if not greedy),
>>>> see [
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
>>>> |
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
>>>> ]

>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>> both gatherers keep it sorted.

>>>>> Making specific, rare, combinations of operations faster at the expense of
>>>>> making 99% of all others slower is a hard pill for most to swallow.

>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>> and i do not understand how it can make the other operations slower.

>>>>> Cheers,
>>>>> ?

>>>> regards,
>>>> R?mi

>>>>> Viktor Klang
>>>>> Software Architect, Java Platform Group
>>>>> Oracle

>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>> Sent: Thursday, 18 January 2024 10:28
>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>> <psandoz at openjdk.java.net>
>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>> propagated

>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>>>>> <core-libs-dev at openjdk.java.net>
>>>>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>> Hi R?mi,

>>>>>> You can find some of my benches here: [
>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>>>>> |
>>>>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>>>>> ]

>>>>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>>>>> didn't end up worth it when looking at the bench results over a wide array of
>>>>>> stream sizes and number of operations.

>>>>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>>>>> KEEP_DISTINCT and KEEP_SIZED,
>>>>> all of them say that if the stream was sorted/distinct/sized then the stream
>>>>> returned by a call to gather() is still sorted (with the same comparator),
>>>>> distinct or sized.

>>>>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>>>>> windowFixed is KEEP_DISTINCT.

>>>>> [CC Paul, so he can correct me if i'm saying something stupid]

>>>>> Now for the benchmarks, it depends what you want to measure, benchmarking
>>>>> streams is tricky. This is what i know about benchmarking streams.
>>>>> First, the JIT has two ways to profile types at runtime,
>>>>> Either a method takes a function as parameter
>>>>> void map(Function function) {
>>>>> function.apply(...)
>>>>> }
>>>>> and when map is called with a subtype of Function, the JIT will propagate the
>>>>> exact type when map is inlined,
>>>>> Or a method use a field
>>>>> class Op {
>>>>> Function function;

>>>>> void map() {
>>>>> function.apply(...)
>>>>> }
>>>>> }
>>>>> in that case, the VM records the profile of function.apply() and if there are
>>>>> more than two different profiles, the VM declare profile poluttion and do not
>>>>> try to optimize.

>>>>> The Stream implementation tries very hard to use only parameters instead of
>>>>> fields, that's why it does not use classical Iterator that are pull iterator (a
>>>>> filter iterator requires a field) but a Spliterator which is a push iterator,
>>>>> the element is sent as parameter of the consumer.That's also why collect does
>>>>> not use the builder pattern (that accumulate values in fields) but a Collector
>>>>> that publish the functions to be called as parameter.

>>>>> Obvisously, this is more complex than that, a Collector stores the functions in
>>>>> fields so it should not work well but the implementation uses a record that
>>>>> plays well with escape analysis. Escape analysis see the fields of an instance
>>>>> as parameters so the functions of a Collector are correctly propagated (if the
>>>>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>>>>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>>>>> are routinely fully inlined with the intermediate operation of a stream.

>>>>> In your tests, i've not seen comparaisons between an existing method like map()
>>>>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>>>>> where the characteristics KEEP_* have an impact and their equivalent using a
>>>>> Gatherer.

>>>>>> Cheers,
>>>>>> ?

>>>>> regards,
>>>>> R?mi

>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle

>>>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>>>>> <forax at univ-mlv.fr>
>>>>>> Sent: Wednesday, 17 January 2024 16:48
>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>> Subject: Gatherer: spliterator characteristics are not propagated
>>>>>> While doing some benchmarking of the Gatherer API, i've found that the
>>>>>> characteristics of the spliterator was not propagated by the method
>>>>>> Stream.gather() making the stream slower than it should.

>>>>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>>>>> that this intermediate operation keep the size, which is important if the
>>>>>> terminal operation is toList() because if the size is known, toList() will
>>>>>> presize the List and avoid the creation of an intermediary ArrayList.

>>>>>> See [
>>>>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>>>>> |
>>>>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>>>>> ]

>>>>>> I think that adding a way to propagate the spliterator characteristics through a
>>>>>> Gatherer would greatly improve the performance of commons streams (at least all
>>>>>> the ones that end with a call to toList).

>>>>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>>>>> something and if improving the performance is something worth changing the API.

>>>>>> regards,
>>>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240125/21a2455e/attachment-0001.htm>

From qamai at openjdk.org  Thu Jan 25 14:01:59 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 25 Jan 2024 14:01:59 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v7]
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <LLt2-zCWyMXBn30mOdLNdkyiAevoPy49VrmOGg9lB9Q=.cc37047e-63da-4764-b0d3-a734668262ba@github.com>

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  change expr to val, add examples

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17527/files
  - new: https://git.openjdk.org/jdk/pull/17527/files/b4445e2e..84f9f7eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17527&range=05-06

  Stats: 51 lines in 1 file changed: 28 ins; 4 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17527/head:pull/17527

PR: https://git.openjdk.org/jdk/pull/17527

From qamai at openjdk.org  Thu Jan 25 14:02:00 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 25 Jan 2024 14:02:00 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <JmyZ7tlQuDaMsJbTqA5fuLALW_DeW3lBIMAyA2otXJA=.2059cb31-605b-45e0-8d3f-ee13574472fe@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
 <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
 <zbsXRUIds6SIhWkbcbhrworYyO3IM9zsH4LNNlXsaW8=.0507c3ae-68da-4411-bcf0-8a262eb451c3@github.com>
 <JmyZ7tlQuDaMsJbTqA5fuLALW_DeW3lBIMAyA2otXJA=.2059cb31-605b-45e0-8d3f-ee13574472fe@github.com>
Message-ID: <hdnYK7Nevd8Qv7--JfLPM5OvcTHlEcCiT-CSf3lTLAI=.623a2be7-b993-45a9-80f1-88249cb6fd36@github.com>

On Thu, 25 Jan 2024 12:52:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> > Naive question: the right way to use this would be almost invariably be like this:
>>> > ```
>>> > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>>> >     // fast-path
>>> > }
>>> > // slow path
>>> > ```
>>> > 
>>> > 
>>> >     
>>> >       
>>> >     
>>> > 
>>> >       
>>> >     
>>> > 
>>> >     
>>> >   
>>> > Right?
>>> 
>>> Yes, I think so.
>> 
>> But then whatever is in the fast path and `fooHasCertainStaticProperties` are never profiled because never executed by the interpreter or c1. So `fooHasCertainStaticProperties` will likely not be inlined and c2 will do a poor (or rather not as good as you'd like) job of compiling whatever is in the fast path.
>
>> > > Naive question: the right way to use this would be almost invariably be like this:
>> > > ```
>> > > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>> > >     // fast-path
>> > > }
>> > > // slow path
>> > > ```
>> > > 
>> > > 
>> > >     
>> > >       
>> > >     
>> > > 
>> > >       
>> > >     
>> > > 
>> > >     
>> > >   
>> > > Right?
>> > 
>> > 
>> > Yes, I think so.
>> 
>> But then whatever is in the fast path and `fooHasCertainStaticProperties` are never profiled because never executed by the interpreter or c1. So `fooHasCertainStaticProperties` will likely not be inlined and c2 will do a poor (or rather not as good as you'd like) job of compiling whatever is in the fast path.
> 
> I suppose perhaps it is implied that `fooHasCertainStaticProperties` should have `@ForceInline` ? But yes, there seems to be several assumptions in how this logic is supposed to be used, and at the moment, it seems to me more of a footgun than something actually useful (but I admit my ignorance on the subject).

@mcimadamore Yes this is hard to use apart from the simple cases. Considering we have already used this technique in the `MethodHandle` implementation, I think there are valid use cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1910271891

From qamai at openjdk.org  Thu Jan 25 14:02:01 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 25 Jan 2024 14:02:01 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v5]
In-Reply-To: <bvM4JToLRGnJg-ycNXH4SL6-icVr2LTXIzGbKcM1Rf0=.32cd4083-5655-418b-b5cc-8ace67c8b34d@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <lQpR2zdArhJjazqbqioBoui7uwjFWCeueiva3O-QQgs=.c567c6a6-fadb-4fb5-bcf0-a6bad7db095d@github.com>
 <gGjwTDexKP8FDU8dOwPhbU8xxlRkRBYv37rEm__qsAQ=.31056201-c11f-4254-82f3-9dc5d7c93961@github.com>
 <_pAlUJwzkoFkCnQW_IQK-zUkUMMjq6KjZoDldS34CyA=.984549da-d6de-4977-a87f-18a33d58824d@github.com>
 <5AWq0nDx_AQPwnEp1cMisZ6ytn2ieq9FHDwDQp5A4QQ=.5043ac3e-04bf-4fd8-a680-448f392e5cb1@github.com>
 <9iDFu8I4w_i1Uso5q7oEi0Le1JvgDNgNyuSZlmKQiuE=.5739d448-fc73-4bcf-bec8-26b3a1b75d21@github.com>
 <WxiAGRmZe3zH9xWJHmrwz20Q_nrbHkLG3CU6624u7nY=.2cd1b7d0-2aaa-4a30-92a0-7027d500c0ed@github.com>
 <-msFouQp2kpWPf6LTKgbDAeLPUkfET6wVesLbAz-6T4=.54ca377c-2e49-4229-a060-daa34485eead@github.com>
 <bvM4JToLRGnJg-ycNXH4SL6-icVr2LTXIzGbKcM1Rf0=.32cd4083-5655-418b-b5cc-8ace67c8b34d@github.com>
Message-ID: <pEibUGphIHe65nimdoLlNaILmU_Sqhqez33AJHKF8LU=.cb89bf72-12b7-48e0-9720-f427d983d67f@github.com>

On Thu, 25 Jan 2024 05:06:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I agree. All values are produced by evaluating expressions. In this case we want to query whether a value produced by the compiler evaluating its expression is a constant value (inputs to the expression are constants and the expression had no material side-effects). Meaning if the method returns true then we could use that knowledge in subsequent expressions that may also produce constants or some specific behavior.
>
>> the method compilation has the expression in its original form
> 
> So the JIT analyses the bytecode used to place the result on the call stack, before the call, and from that determines if the expression were a constant? This kind of self-analysis is not something I was aware of.

I see, changed `expr` to `val`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17527#discussion_r1466418470

From mcimadamore at openjdk.org  Thu Jan 25 14:51:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jan 2024 14:51:36 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <JmyZ7tlQuDaMsJbTqA5fuLALW_DeW3lBIMAyA2otXJA=.2059cb31-605b-45e0-8d3f-ee13574472fe@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
 <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
 <zbsXRUIds6SIhWkbcbhrworYyO3IM9zsH4LNNlXsaW8=.0507c3ae-68da-4411-bcf0-8a262eb451c3@github.com>
 <JmyZ7tlQuDaMsJbTqA5fuLALW_DeW3lBIMAyA2otXJA=.2059cb31-605b-45e0-8d3f-ee13574472fe@github.com>
Message-ID: <wFpFe_BINiS4L-1-2GD7Gj7crapneA1YC8nLwtKX2ik=.3174a0e7-84ee-4eaa-b1c4-d61b1ee519a4@github.com>

On Thu, 25 Jan 2024 12:52:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> > Naive question: the right way to use this would be almost invariably be like this:
>>> > ```
>>> > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>>> >     // fast-path
>>> > }
>>> > // slow path
>>> > ```
>>> > 
>>> > 
>>> >     
>>> >       
>>> >     
>>> > 
>>> >       
>>> >     
>>> > 
>>> >     
>>> >   
>>> > Right?
>>> 
>>> Yes, I think so.
>> 
>> But then whatever is in the fast path and `fooHasCertainStaticProperties` are never profiled because never executed by the interpreter or c1. So `fooHasCertainStaticProperties` will likely not be inlined and c2 will do a poor (or rather not as good as you'd like) job of compiling whatever is in the fast path.
>
>> > > Naive question: the right way to use this would be almost invariably be like this:
>> > > ```
>> > > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
>> > >     // fast-path
>> > > }
>> > > // slow path
>> > > ```
>> > > 
>> > > 
>> > >     
>> > >       
>> > >     
>> > > 
>> > >       
>> > >     
>> > > 
>> > >     
>> > >   
>> > > Right?
>> > 
>> > 
>> > Yes, I think so.
>> 
>> But then whatever is in the fast path and `fooHasCertainStaticProperties` are never profiled because never executed by the interpreter or c1. So `fooHasCertainStaticProperties` will likely not be inlined and c2 will do a poor (or rather not as good as you'd like) job of compiling whatever is in the fast path.
> 
> I suppose perhaps it is implied that `fooHasCertainStaticProperties` should have `@ForceInline` ? But yes, there seems to be several assumptions in how this logic is supposed to be used, and at the moment, it seems to me more of a footgun than something actually useful (but I admit my ignorance on the subject).

> @mcimadamore Yes this is hard to use apart from the simple cases. Considering we have already used this technique in the `MethodHandle` implementation, I think there are valid use cases.

I don't 100% buy the `MethodHandleImpl` analogy. In that case the check is not simply used to save a branch, but to spare spinning of a completely new lambda form. That is a very heavy operation. What I'm trying to say is that I'm not too sure how robust of a mechanism this is in the context of micro(nano?)-optimizations (such as the one you are considering).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1910359911

From rriggs at openjdk.org  Thu Jan 25 14:54:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 25 Jan 2024 14:54:57 GMT
Subject: Integrated: 8324657: Intermittent OOME on exception message create
In-Reply-To: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
References: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
Message-ID: <BWjXy61kQcYU6QdWYTtzFrphh3nNdb63CVcDXWl7rWs=.8e7e365f-2bc3-446e-8449-8c37c33fe480@github.com>

On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
> Explicit use of String.concat() call can improve exception handling.
> 
> Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

This pull request has now been integrated.

Changeset: ffe3bb67
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffe3bb67632eeec4b5df4e832d9bd5e78c3f808a
Stats:     15 lines in 1 file changed: 8 ins; 2 del; 5 mod

8324657: Intermittent OOME on exception message create

Reviewed-by: lancea, iris, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17522

From rriggs at openjdk.org  Thu Jan 25 14:54:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 25 Jan 2024 14:54:55 GMT
Subject: RFR: 8324657: Intermittent OOME on exception message create [v2]
In-Reply-To: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
References: <rOqzErUT67YvIUQrP5ofu_dRyOyrKBtfBP9vw5cqSvw=.9d8f3060-04b9-44a2-8b92-e2a2fd1fd9e7@github.com>
Message-ID: <_Htafhg1du_Z87RanLCuCE3AgX5MySe9isug7u7ZJ5A=.8b1b642c-b301-486e-861b-7f8add89bcbc@github.com>

> When an exception handler for an OutOfMemoryError uses string concatenation to compose an exception message, the invoke dynamic string format implementation may itself exhaust memory, preventing the exception from being handled.
> Explicit use of String.concat() call can improve exception handling.
> 
> Writing a test of the exact failure condition has proved challenging due to the unpredictable state of memory when OOME occurs. The replacement of "+" with String.concat() is simple and direct.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Wrap long line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17522/files
  - new: https://git.openjdk.org/jdk/pull/17522/files/bfe60737..e83eb84b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17522&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17522&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17522/head:pull/17522

PR: https://git.openjdk.org/jdk/pull/17522

From shade at openjdk.org  Thu Jan 25 15:36:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Jan 2024 15:36:39 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v6]
In-Reply-To: <wFpFe_BINiS4L-1-2GD7Gj7crapneA1YC8nLwtKX2ik=.3174a0e7-84ee-4eaa-b1c4-d61b1ee519a4@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <k1hqRKLjR4TZACwosOU-5wJpTxF0QGTmNKvbkvRo8fo=.8c9e3a3a-7cdc-4ba1-a636-8d9156a41bcb@github.com>
 <9SikKzxs8M1JdTLvTB6JTozvpCw2CSziF2koHw0ELAQ=.fb2e7696-6fa6-4a2b-87b8-ec57d4fef05c@github.com>
 <ZuBv7o6H6sZsVRe9Asxp0GyUwF5rP3QZci1hG-ES2OA=.faee13f6-ae2a-4baa-ab35-1fb12a1a0a35@github.com>
 <e2Q9Yioz3CxxKvRIV0JGgEB_NeSOE-MQ98-0MvIT5Zs=.0b71460c-7913-46be-81fb-3ff410ecc6a9@github.com>
 <zbsXRUIds6SIhWkbcbhrworYyO3IM9zsH4LNNlXsaW8=.0507c3ae-68da-4411-bcf0-8a262eb451c3@github.com>
 <JmyZ7tlQuDaMsJbTqA5fuLALW_DeW3lBIMAyA2otXJA=.2059cb31-605b-45e0-8d3f-ee13574472fe@github.com>
 <wFpFe_BINiS4L-1-2GD7Gj7crapneA1YC8nLwtKX2ik=.3174a0e7-84ee-4eaa-b1c4-d61b1ee519a4@github.com>
Message-ID: <RuQcfPGjDLkro7NQEn4rdshwnmG1zcohqe4HM87X_x0=.af940f33-c122-43d4-94b6-8295219750eb@github.com>

On Thu, 25 Jan 2024 14:48:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I don't 100% buy the `MethodHandleImpl` analogy. In that case the check is not simply used to save a branch, but to spare spinning of a completely new lambda form.

Doing this to save a few intructions would not likely to worth the hassle outside the _really performance critical paths_, but even then it might be useful for hot JDK code. On larger examples, you can avoid memory accesses, allocations, etc. by coding up the constant-foldable path that you know compiler would not be able to extract when propagating constants through the generic code. For example, giving quantitative substance to my previous example:


diff --git a/src/java.base/share/classes/java/lang/Integer.java b/src/java.base/share/classes/java/lang/Integer.java
index 1c5b3c414ba..d50748c369e 100644
--- a/src/java.base/share/classes/java/lang/Integer.java
+++ b/src/java.base/share/classes/java/lang/Integer.java
@@ -28,4 +28,5 @@
 import jdk.internal.misc.CDS;
 import jdk.internal.misc.VM;
+import jdk.internal.vm.ConstantSupport;
 import jdk.internal.vm.annotation.ForceInline;
 import jdk.internal.vm.annotation.IntrinsicCandidate;
@@ -416,4 +417,7 @@ private static void formatUnsignedIntUTF16(int val, int shift, byte[] buf, int l
     }
 
+    @Stable
+    static final String[] TO_STRINGS = { "-1", "0", "1" };
+
     /**
      * Returns a {@code String} object representing the
@@ -428,4 +432,8 @@ private static void formatUnsignedIntUTF16(int val, int shift, byte[] buf, int l
     @IntrinsicCandidate
     public static String toString(int i) {
+        if (ConstantSupport.isCompileConstant(i) &&
+                (i >= -1) && (i <= 1)) {
+            return TO_STRINGS[i + 1];
+        }
         int size = stringSize(i);
         if (COMPACT_STRINGS) {
diff --git a/test/micro/org/openjdk/bench/java/lang/Integers.java b/test/micro/org/openjdk/bench/java/lang/Integers.java
index 43ceb5d18d2..28248593a73 100644
--- a/test/micro/org/openjdk/bench/java/lang/Integers.java
+++ b/test/micro/org/openjdk/bench/java/lang/Integers.java
@@ -91,4 +91,18 @@ public void decode(Blackhole bh) {
     }
 
+    @Benchmark
+    @OutputTimeUnit(TimeUnit.NANOSECONDS)
+    public String toStringConstYay() {
+        return Integer.toString(0);
+    }
+
+    int v = 0;
+
+    @Benchmark
+    @OutputTimeUnit(TimeUnit.NANOSECONDS)
+    public String toStringConstNope() {
+        return Integer.toString(v);
+    }
+
     /** Performs toString on small values, just a couple of digits. */
     @Benchmark



Benchmark                                      (size)  Mode  Cnt      Score     Error   Units
Integers.toStringConstNope                        500  avgt   15      3,599 ?   0,034   ns/op
Integers.toStringConstNope:gc.alloc.rate.norm     500  avgt   15     48,000 ?   0,001    B/op
Integers.toStringConstNope:gc.time                500  avgt   15    223,000                ms
Integers.toStringConstYay                         500  avgt   15      0,568 ?   0,046   ns/op
Integers.toStringConstYay:gc.alloc.rate.norm      500  avgt   15     ? 10??              B/op


Think about it as simplifying/avoiding the need for full compiler intrinsics. I could, in principle, do this by intrinsifying `Integer.toString` completely, check the same `isCon`, and then either construct the access to some String constant, or arrange the call to actual toString slow path. That would not be as simple as doing the similar thing in plain Java, with just a little of compiler support in form of `ConstantSupport`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1910449450

From lmesnik at openjdk.org  Thu Jan 25 17:00:38 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 25 Jan 2024 17:00:38 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <-quimoVBzziosvz8NKyrp0fop7T9ZRDg4SJo1wif6aw=.77948f6f-0728-4e57-ae98-5c5472f435ee@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
 <-quimoVBzziosvz8NKyrp0fop7T9ZRDg4SJo1wif6aw=.77948f6f-0728-4e57-ae98-5c5472f435ee@github.com>
Message-ID: <MbYpxniBs0AAgNbTeTXamc8HG_HsSKk7ZqcLiW9Nw20=.d3d045fd-f2d2-4f97-98f6-d5d3ac8f744b@github.com>

On Wed, 24 Jan 2024 21:28:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
>> 
>> I provisionally call this flag `external-dep`, but I am open for other suggestions.
>> 
>> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
>> 
>> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
>> 
>> Additional testing:
>>  - [x] `make test TEST=applications/` fails
>>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests
>
> Marked as reviewed by lmesnik (Reviewer).

> @lmesnik, you good with the keyword name?

Yes, I'm fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1910613276

From abimpoudis at openjdk.org  Thu Jan 25 17:33:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 17:33:14 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v53]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <KIT17QSUGnDWozPRmmDNl8fmiAmpvrRv4vwRLR-iVbM=.daeab00c-9c4d-49a3-a89d-5968de6f4525@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:

  Tidy up Javadoc of Lower.visitTypeTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/b77d2316..44634684

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=51-52

  Stats: 28 lines in 1 file changed: 9 ins; 5 del; 14 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  Thu Jan 25 17:46:07 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 25 Jan 2024 17:46:07 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v54]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <0P6DMz53NNbzFireeMjPkayWCA93kTUGv0yAH9j-yP0=.27ec38d2-aa91-4aba-9d88-d94978d42abb@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:

  Small fix in Javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/44634684..854c20a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=52-53

  Stats: 1 line in 1 file changed: 0 ins; 0 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 shade at openjdk.org  Thu Jan 25 18:05:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Jan 2024 18:05:39 GMT
Subject: RFR: 8323717: Introduce test keyword for tests that need external
 dependencies
In-Reply-To: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
Message-ID: <ee9uJEZ77ueIXxEz7dP0P_QLsHhjUddREke179VBGnQ=.fd30a6fb-dc80-4b92-af7c-f9e808dbdf93@github.com>

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
> 
> I provisionally call this flag `external-dep`, but I am open for other suggestions.
> 
> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
> 
> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
> 
> Additional testing:
>  - [x] `make test TEST=applications/` fails
>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests

Awesome, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1910723514

From shade at openjdk.org  Thu Jan 25 18:05:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Jan 2024 18:05:40 GMT
Subject: Integrated: 8323717: Introduce test keyword for tests that need
 external dependencies
In-Reply-To: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
References: <rStMwtK_l_3WPapEYOZ7FuHPtLyt98qMTLsg1CsEHV8=.0ddbbd7c-72a3-4115-b536-b198648c534e@github.com>
Message-ID: <7-XWGMcg4_0LkPgaUwPBolYkQe0Wg33bsDvNec2zdRo=.796bd2b0-bdd2-4e35-af38-d0ea9578ec43@github.com>

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some jtreg tests require resolvable external dependencies. This resolution is delegated to JIB, which is not used in vanilla OpenJDK testing. It would be convenient to add a keyword that marks tests that require these external dependencies, so that we could exclude those tests from runs. This would allow us to: a) run all tests in hotspot:tier4, which now excludes `applications/` specifically; b) make all tests runs (#17422) cleaner on many environments.
> 
> I provisionally call this flag `external-dep`, but I am open for other suggestions.
> 
> Note that some tests that pull `@Artifact`-s provide special paths that do limited testing anyway. However, there are tests which cannot run without external dependencies at all. These include at least `applications/jcstress` and `applications/scimark` tests.
> 
> Ironically, I cannot run the jcstress test generator because the dependencies are lacking here. I regenerated those test using a self-built jcstress 0.16 bundle.
> 
> Additional testing:
>  - [x] `make test TEST=applications/` fails
>  - [x]  `JTREG_KEYWORDS=!external-dep make test TEST=applications/` passes, skipping most of the tests

This pull request has now been integrated.

Changeset: 12b89cd2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12b89cd2eeb5c2c43a2ce425c96fc4f718e30514
Stats:     62 lines in 32 files changed: 32 ins; 0 del; 30 mod

8323717: Introduce test keyword for tests that need external dependencies

Reviewed-by: dholmes, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/17421

From acobbs at openjdk.org  Thu Jan 25 21:38:54 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 25 Jan 2024 21:38:54 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Change MessageFormat.toPattern() @implNote to @implSpec.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/58e8cc68..7f96511e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From jlu at openjdk.org  Thu Jan 25 22:52:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 Jan 2024 22:52:30 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
Message-ID: <8aC3_aHIyJ07yrMtT2GmTdQySoPigx8XP6IJDOuG8bY=.6de28f98-2b95-4927-95a8-0c5af7f61e31@github.com>

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MessageFormat.toPattern() @implNote to @implSpec.

Hi Archie, thanks for the updates,

I did testing with some more edge cases, and everything still looks good to me. 

In terms of the CSR,

- Can you update the CSR with the `implSpec` tag as well? 
- Although definitely relevant, I'm not sure if the _special behavior_ section is too involved for a CSR. Perhaps you can move that section to a comment or make it apart of the description in the PR instead?
> After this change, the result of fmt2.toPattern() will be the same as fmt1.toPattern(). 
- While true, I think you should make it apparent that after the change, fmt1.toPattern() returns `{0,number,:'}' #0.##}` now, instead of `{0,number,:} #0.##}`.

Once you make these changes, I will mark it as reviewed by me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1911121617

From acobbs at openjdk.org  Thu Jan 25 23:05:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 25 Jan 2024 23:05:35 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <8aC3_aHIyJ07yrMtT2GmTdQySoPigx8XP6IJDOuG8bY=.6de28f98-2b95-4927-95a8-0c5af7f61e31@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <8aC3_aHIyJ07yrMtT2GmTdQySoPigx8XP6IJDOuG8bY=.6de28f98-2b95-4927-95a8-0c5af7f61e31@github.com>
Message-ID: <oTV5oabwm2Q04qpcKVBPX_WdxPCifbK0_UL_G6ipXGU=.847ed924-6e42-4c60-b238-403c5504005b@github.com>

On Thu, 25 Jan 2024 22:49:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> In terms of the CSR,...

Hi Justin, thanks again very much for the comments and careful review. The CSR should be updated accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1911134650

From bchristi at openjdk.org  Thu Jan 25 23:09:51 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 25 Jan 2024 23:09:51 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v7]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <f7xiLmhBedF-ZWjCwx0cDlwLSmZPK76Be-XnTMPN5Ug=.75563fb4-07a4-43e6-a757-f4a7a66479b2@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:

  Updates to clear() and enqueue()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/3647f64a..7eb3397c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=05-06

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 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  Thu Jan 25 23:09:54 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 25 Jan 2024 23:09:54 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v6]
In-Reply-To: <LuF-mEGXN98FB7WBm4hkD2ZVye8WoiTRjcTY4JYOV1k=.6c2d8164-0db6-4377-9e0b-9be9197421ca@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <VU_oK39fLPRq6d32t1tvSLIHLTOdIItkGsTbXuVcKAM=.2b939eb4-0610-4efb-af28-3c9025100e58@github.com>
 <LuF-mEGXN98FB7WBm4hkD2ZVye8WoiTRjcTY4JYOV1k=.6c2d8164-0db6-4377-9e0b-9be9197421ca@github.com>
Message-ID: <FpMftZw83e_6W_Ru6tScBdYYMkDJ313p33RYWxak7jU=.690146da-df7a-400c-aba4-3a16bd8318a2@github.com>

On Tue, 23 Jan 2024 11:40:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak Reference.enqueue memory consistency effects wording
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 508:
> 
>> 506:      * Use of this method allows the registered queue's
>> 507:      * {@link ReferenceQueue#poll} and {@link ReferenceQueue#remove} methods
>> 508:      * to return this reference even though the referent is still strongly
> 
> Perhaps s/is still/may still be/

Sure, sounds good

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1467059185

From duke at openjdk.org  Fri Jan 26 00:20:46 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 00:20:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <G-3j-YJ-BW1budiSq44FNc7d7DewmnmczBVySYWq0qo=.e2d7de0e-ad55-451c-b3b4-427baa687489@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <G-3j-YJ-BW1budiSq44FNc7d7DewmnmczBVySYWq0qo=.e2d7de0e-ad55-451c-b3b4-427baa687489@github.com>
Message-ID: <J26pnHX2kDxTc6bHPAZxljwy88hUoDOXutM6A0PFQng=.5e44d19c-bd0b-4169-a190-66b849697e8c@github.com>

On Thu, 25 Jan 2024 13:33:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.
>> 
>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation. This also caters the need to inject utility classes from an agent before any class file transformer is triggered, to maintain a well-defined life-cycle.
>> 
>> Of course I'd prefer if there was a way to resolve a lookup from Instrumentation for a given class loader and for example a package-info class, however rendering the issue that packages might not exist (yet).
>
>> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.
> 
> How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null Instrumentation object (a value which any agent ought to keep secret). However, it could just as easily have employed an arbitrary bit length hash key. The key can be used to initialize a module-private static long[] field of an API implementation class generated into the module i.e. the hole can actually be a keyhole in the shape of a key known only to the API client and implementation.

Thanks @adinn, @raphw for your feedback. I am not pretending to fully understand what you just explained or to have the slightest clue how to do what you suggested, but reading it for the second time since yesterday seems to make it clearer already. I guess, I cannot hope for a how-to with sample code. But I can immerse myself into the topic some more next time I have a vacant time box and look at Byte Buddy and Byteman source code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911208017

From vromero at openjdk.org  Fri Jan 26 01:04:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Jan 2024 01:04:33 GMT
Subject: RFR: 8323835: Updating ASM to 9.6 for JDK 23
In-Reply-To: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
References: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
Message-ID: <vlxu5HcMRhDiKq3kE-RfKaL5EUbxFUWixVn1U5Wj27w=.dbc52694-5ffa-44f0-8eb1-5f53ef3133ee@github.com>

On Tue, 16 Jan 2024 21:18:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Updating ASM to version 9.6,
> 
> Thanks in advance for the reviews,
> Vicente

hi Mandy, thanks for your comments,

> The change looks okay to me. Most of the changes are doc change. I see many files are updated just to remove the empty line at the end of the file - is that intentional, imported from this upgrade?

yes this is intentional, this change somehow aligns with what we do with our sources that's why I kept it 

> 
> Any need to update the copyright header? The new file CheckFrameAnalyzer.java still has the same copyright header years as other files. I assume no need then?

yes there is no need to update them, we never update the year on the copyright of ASM sources

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17453#issuecomment-1911245663

From mchung at openjdk.org  Fri Jan 26 01:39:26 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Jan 2024 01:39:26 GMT
Subject: RFR: 8323835: Updating ASM to 9.6 for JDK 23
In-Reply-To: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
References: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
Message-ID: <ovgeQL_IV6Vp_aflZlETvJAzimwExyloakAqyDGth0s=.e450fc46-9eb8-4ef7-b10d-cefa8f3e3310@github.com>

On Tue, 16 Jan 2024 21:18:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Updating ASM to version 9.6,
> 
> Thanks in advance for the reviews,
> Vicente

Looks okay to me.   I would rely on your testing for verification.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17453#pullrequestreview-1844965253

From duke at openjdk.org  Fri Jan 26 08:04:47 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 08:04:47 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
Message-ID: <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>

On Thu, 25 Jan 2024 12:16:13 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.

@raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911633482

From alanb at openjdk.org  Fri Jan 26 08:30:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Jan 2024 08:30:42 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
Message-ID: <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>

On Fri, 26 Jan 2024 08:01:59 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
> 
> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.

Agents should not be using the JDK's internal Unsafe. This needs to said in the strongest possible terms.

For the discussion, it would be useful to provide a brief summary on what AspectJ is trying to do with this weaving. This PR was originally about load time instrumentation defining auxiliary classes, as you might get at compile time when compiling a source file containing more than one class.. I can't tell from your comments here or in Eclipse 546305 if this is relevant to what you are trying to do or not. It may even be better to start a new discussion on serviceability-dev.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911661044

From duke at openjdk.org  Fri Jan 26 08:47:44 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 08:47:44 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
Message-ID: <t-Zkp_lqkhdGjGTixtyumF5Zh-SAY_746-ppG11UoBw=.2c6eb2ed-8ad4-4b76-980d-392b62eaccf6@github.com>

On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
>
>> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
> 
> Agents should not be using the JDK's internal Unsafe. This needs to said in the strongest possible terms.
> 
> For the discussion, it would be useful to provide a brief summary on what AspectJ is trying to do with this weaving. This PR was originally about load time instrumentation defining auxiliary classes, as you might get at compile time when compiling a source file containing more than one class.. I can't tell from your comments here or in Eclipse 546305 if this is relevant to what you are trying to do or not. It may even be better to start a new discussion on serviceability-dev.

@AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception.

The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.

IMO, this is absolutely on topic, which is why the Bugzilla bug is linked to the JDK issue and was discussed with Mandy in this context.

@AlanBateman: As for using means to achieve user benefit that the JDK team deems unfit, nobody would do that, if there was an adequate way to provide such user value. Neither AspectJ nor Byte Buddy have a reputation of being some kind of shady hacker tools.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911676808
PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911680020

From winterhalter at openjdk.org  Fri Jan 26 08:47:46 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Fri, 26 Jan 2024 08:47:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <dqRnJg7KSWR12Vm4fK8xWAkr4guZoOtYmvTnxmQEbEo=.f92c55e3-f3e6-4da9-9fab-1dedc527ac2c@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

I migrate the day https://bugs.openjdk.org/browse/JDK-8200559 finds a solution (and fallback for older JDKs).

I can start a new discussion, but briefly summarized from the last time this was on the mailing list:

- Agents sometimes need to add classes, for example when intercepting a reactive API where a modified callback subclass is injected, with an extra field, for instance.
- The suggestion was that an argument would be provided to ClassFileTransformer which would allow adding classes to the current package. A prototype was created.
- The (my) counter argument was that communication between two packages would be difficult then, as the agent does not control class loading order. If the reactive receiver would need to cast a callback object to read the field that was added, the agent's class might not yet have been instrumented and the class would not exist, yielding an error. The receiver instrumebtation can neither inject the class.
- Often there is also a need to inject infrastructure into class loaders/modules that the instrumentation relies on, so I argued that the facility shouldn't be added to ClassFileTransformer to begin with, but to Instrumentation. Otherwise one could also "pseudo-transform" classes to inject infrastructure, but that felt unnecessary.
- The discussion staled thereafter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911679253

From alanb at openjdk.org  Fri Jan 26 08:41:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Jan 2024 08:41:35 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v9]
In-Reply-To: <4wvO-Q9bbbg4kFD1u3yJSt8aazvW5BP9eLp4epde4AU=.6a27769a-7be9-49ce-af41-d85ed5232c55@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <4wvO-Q9bbbg4kFD1u3yJSt8aazvW5BP9eLp4epde4AU=.6a27769a-7be9-49ce-af41-d85ed5232c55@github.com>
Message-ID: <Mb7KJbUx0IYaM1Aqe4RjgYlFaZgQAkJIuDFcGIYbh-s=.6fd79cc2-6c5b-4db2-8ef0-1c0c06eaa616@github.com>

On Wed, 24 Jan 2024 13:23:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update String.java

src/java.base/share/classes/java/lang/String.java line 4238:

> 4236:      * @return String with escape sequences and unicode escapes translated.
> 4237:      *
> 4238:      * @implNote Normally, unicode escapes are translated by the compiler before string

A minor comment on the implNote is that it better to drop "Normally," from the beginning of this sentence and "However," from the second sentence. I think it would read a bit better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467358224

From duke at openjdk.org  Fri Jan 26 09:12:42 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 26 Jan 2024 09:12:42 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@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>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
Message-ID: <iNzAGx4HRT5gERuEsFGmDSa5DZ6EWmxBnikBwUYdlYQ=.ccf89134-7ed2-492c-96e4-c90cd18b38c9@github.com>

On Thu, 18 Jan 2024 21:36:22 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> 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
> ...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run the benchmarking of new DQPS in your environment with AVX?
> 
> Take all classes below and put them in the package org.openjdk.bench.java.util.
> ArraysSort class contains all tests for the new versions and ready to use.
> (it will run all tests in one execution).
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
> 
> Many thanks,
> Vladimir

Hello Vladimir (@iaroslavski),

Could you please share your pom.xml as am running into issues when the JHM benchmark is run:

`java.lang.IllegalAccessError: class org.openjdk.bench.java.util.DualPivotQuicksort_a15 (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426`

Added the following add-exports in pom.xml, but it's still not working.


<plugin>
    <groupId>org.apache.maven.plugins</groupId>
        	<artifactId>maven-compiler-plugin</artifactId>
        	<version>3.8.1</version>
        	<configuration>  
                   <compilerArgs>
                  	 <arg>--add-exports</arg>
                  	  <arg>java.base/jdk.internal.misc=ALL-UNNAMED</arg>
                          <arg>--add-exports</arg>
                          <arg>java.base/jdk.internal.vm.annotation=ALL-UNNAMED</arg>
          	    </compilerArgs>
        	</configuration>
  </plugin>      				


Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1911712234

From alanb at openjdk.org  Fri Jan 26 09:15:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Jan 2024 09:15:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
Message-ID: <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>

On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
>
>> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
> 
> Agents should not be using the JDK's internal Unsafe. This needs to said in the strongest possible terms.
> 
> For the discussion, it would be useful to provide a brief summary on what AspectJ is trying to do with this weaving. This PR was originally about load time instrumentation defining auxiliary classes, as you might get at compile time when compiling a source file containing more than one class.. I can't tell from your comments here or in Eclipse 546305 if this is relevant to what you are trying to do or not. It may even be better to start a new discussion on serviceability-dev.

> @AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception.
> 
> The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.

Right, this is what JDK-8200559 was originally about. Mandy and I discussed it several times and load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition. 

The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911716353

From duke at openjdk.org  Fri Jan 26 09:33:45 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 26 Jan 2024 09:33:45 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@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>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
Message-ID: <_1zpIa4ufP599oHVXuQt9TCfCHWAicJ4WbV2c-6LNUI=.26e06dd5-4316-4aa4-a505-5c47e5c5b7e5@github.com>

On Thu, 18 Jan 2024 21:36:22 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> 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
> ...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run the benchmarking of new DQPS in your environment with AVX?
> 
> Take all classes below and put them in the package org.openjdk.bench.java.util.
> ArraysSort class contains all tests for the new versions and ready to use.
> (it will run all tests in one execution).
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
> 
> Many thanks,
> Vladimir

Hi Vladimir (@iaroslavski),

I was able to figure out the issue and started the benchmarking JMH run. It's night time here, will provide the data Friday morning (US PST)

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1911741126

From duke at openjdk.org  Fri Jan 26 10:20:44 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 10:20:44 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
Message-ID: <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>

On Fri, 26 Jan 2024 09:12:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition

Thanks for finding some common ground. I appreciate it.

> The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.

I better do not start to share my general opinion about JMS _(edit: sorry, couldn't resist in the end)_ - I mean the ongoing effort that started with Jigsaw - in detail, because that would end up in a flame war.

Let me just say, that "well-meant" is not the necessarily same as "constructive", "helpful" or "necessary". Back when Jigsaw was designed, it seemed to be a good idea. But it has been introduced a long time ago, and all my enterprise customers since then are trying to ignore its excistence as much as they can, mostly seeing it as an impediment or at least a major annoyance. I think, one of the reasons why Python gained so much traction for enterprise-level big data and machine learning stuff is that you have a dynamic language environment in which you can pretty much do whatever you want and just get things done.

Those same enterprise customers want to use the tools of their choosing with as many and as easy to use features as possible. They do not trade those features for security, but implement security in a different way, such as devising a micro service architecture and isolating containers from each other in OpenShift or what have you, defining service mesh rules on top of that, if necessary.

Deprecating security managers was a laudable idea, but adding those unnecessary restrictions in the JVM in exchange was kind of one step forward, two steps back. They just get in the way of getting useful things done. This is what a language and a VM are for: getting things done in a productive way with as few barriers as possible. Instead, with every new Java release, users and tool providers alike are forced to jump through more hoops. There is so much great, innovative stuff in the JVM and Java SE API. E.g., virtual threads are the greatest thing since bread came sliced. We want more of that and fewer barriers. Streams, NIO, the whole lambda and functional bunch of stuff, structured concurrency, better GC, records and neat ways to deconstruct them etc. - wow, great stuff. But new "security features" (a.k.a. restrictions) like modules and sealed classes - not so great from a productivity perspective. Since JDK 9, I have seen generations of developers trying to be more productive no
 t because but despite those new JVM "features".

I know that my perspective is quite subjective and might be biased. But as an agile coach dealing mostly with developers in the JVM ecosystem, I have yet to find a team in which more than a tiny minority thinks that JMS is useful. That is not because they are lazy to learn or do not want to leave their confort zones. It is, because the JVM makes it progressively harder to get things done instead of treating users like adults and letting them take responsibility for security as they see fit. Enforcing things like a helicopter parent is not the smartest move.

I apologise for polluting the thread with what ended up to be too much text that is related to the topic, but not exactly focused on the problem at hand.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911803302

From adinn at openjdk.org  Fri Jan 26 12:29:44 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 26 Jan 2024 12:29:44 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
Message-ID: <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>

On Fri, 26 Jan 2024 10:17:16 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

>>> @AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception.
>>> 
>>> The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.
>> 
>> Right, this is what JDK-8200559 was originally about. Mandy and I discussed it several times and load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition. 
>> 
>> The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.
>
>> load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition
> 
> Thanks for finding some common ground. I appreciate it.
> 
>> The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.
> 
> I better do not start to share my general opinion about JMS _(edit: sorry, couldn't resist in the end)_ - I mean the ongoing effort that started with Jigsaw - in detail, because that would end up in a flame war.
> 
> Let me just say, that "well-meant" is not the necessarily same as "constructive", "helpful" or "necessary". Back when Jigsaw was designed, it seemed to be a good idea. But it has been introduced a long time ago, and all my enterprise customers since then are trying to ignore its existence as much as they can, mostly seeing it as an impediment or at least a major annoyance. I think, one of the reasons why Python gained so much traction for enterprise-level big data and machine learning stuff is that you have a dynamic language environment in which you can pretty much do whatever you want and just get things done.
> 
> Those same enterprise customers want to use the tools of their choosing with as many and as easy to use features as possible. They do not trade those features for security, but implement security in a different way, such as devising a micro service architecture and isolating containers from each other in OpenShift or what have you, defining service mesh rules on top of that, if necessary.
> 
> Deprecating security managers was a laudable idea, but adding those unnecessary restrictions in the JVM in exchange was kind of one step forward, two steps back. They just get in the way of getting useful things done. This is what a language and a VM are for: getting things done in a productive way with as few barriers as possible. Instead, with every new Java release, users and tool providers alike are forced to jump through more hoops. There is so much great, innovative stuff in the JVM and Java SE API. E.g., virtual threads are the greatest thing since bread came sliced. We want more of that and fewer barriers. Streams, NIO, the whole lambda and functional bunch of stuff, structured concurrency, better GC, records and neat ways to deconstruct them etc. - wow, great stuff. But new "security features" (a.k.a. restrictions) like modules and sealed classes - not so great from a productivity perspective. Since JDK 9, I have seen generations of developer...

@kriegaex Luckily, you and your customers are not obliged to use the JPMS, nor find it useful for whatever libraries or apps you write or deploy. However, the fact that you or many other programmers do not use it does not mean it has not been a success. Anyone deeply involved with JDK and/or JVM development in recent years knows that it has been and continues to be critical to maintaining and extending the Java platform.

Regarding my previous comment about Byteman using its own dedicated, dynamic module to provide secure access to MethodLookup instance you might want to look at the relevant code. It relies on a sanctioned API of Instrumentation that was introduced as part of the negotiation of JPMS integration precisely to allow agents to interact with and reconfigurethe module system at runtime. The resulting Byteman code provides a simple API that allows methods to be executed indirectly, either via reflection in jdk8- or via method handles in jdk9+. You can see the details of how I achieved this in the Byteman [layer](https://github.com/bytemanproject/byteman/tree/main/layer) and [jigsaw](https://github.com/bytemanproject/byteman/tree/main/jigsaw) subdirectories.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911993356

From jlaskey at openjdk.org  Fri Jan 26 13:11:28 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:11:28 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v6]
In-Reply-To: <fwMy05TAq6clKrPCyh9V862HGoCAPTEFF8OEhKIc15Y=.313f204b-e031-41c3-a2ab-2a3bc176eec8@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <2S_wsqXlgCtqH7B1T91ey2m8fTfXCiLXKRQFZDxMrPI=.7b1c4f09-0535-447e-93fb-3ec768c2e50e@github.com>
 <fwMy05TAq6clKrPCyh9V862HGoCAPTEFF8OEhKIc15Y=.313f204b-e031-41c3-a2ab-2a3bc176eec8@github.com>
Message-ID: <98Beaay9aTnon1lW_ySDzsLid7Gncu5VVUHJX4vxWCk=.7591f91f-8336-4e5a-9df9-d7a5ca630995@github.com>

On Fri, 19 Jan 2024 17:39:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year of test
>
> test/jdk/java/lang/String/TranslateEscapes.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2024 Oracle and/or its affiliates. All rights reserved.
> 
> Sorry for this late note.
> Seems like each copyright year must be followed by a comma `,`, otherwise validate-source fails. See, for example, my own oversight [here](https://github.com/openjdk/jdk/pull/17490/files).

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467631294

From jlaskey at openjdk.org  Fri Jan 26 13:11:29 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:11:29 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v7]
In-Reply-To: <BBVrlM0S7AIbiv60AyHl51bJgBF6n72ALAfsofM38Vk=.867d8433-e06a-4397-bd1a-6a3b485fd626@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <rcKlB6jaG0Y42hQdSk6rspyvWIVhRnceWC0WKn2wahI=.4298480f-eea4-40c3-a3be-18de0870397e@github.com>
 <BBVrlM0S7AIbiv60AyHl51bJgBF6n72ALAfsofM38Vk=.867d8433-e06a-4397-bd1a-6a3b485fd626@github.com>
Message-ID: <P9ES3LDPf-UGPsWims6u6LmjYkIeW-SCIzm5pj8-R-k=.065fb0f7-ff06-4a62-bdbb-20d9f1c163b8@github.com>

On Fri, 19 Jan 2024 18:27:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright
>
> test/jdk/java/lang/String/TranslateEscapes.java line 127:
> 
>> 125:         } catch (IllegalArgumentException ex) {
>> 126:         }
>> 127:     }
> 
> The method name implies valid unicode escape sequences, but they are all invalid.
> The method name could be "verifyIllegalUnicodeEscape`.

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467632496

From jlaskey at openjdk.org  Fri Jan 26 13:14:38 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:14:38 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v8]
In-Reply-To: <XlqVjLPl-GBZYoma_bQLsRUk9fM5akMbwD6_oI-4RL8=.f6589215-0807-4887-8d52-8a6b33097bfb@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <Blm-6qX2Na94tV7TnvRdunU_t0YLB-Oip7ZIKtttKu4=.db241d1e-507f-4b05-bb0d-260fab82e9ac@github.com>
 <XlqVjLPl-GBZYoma_bQLsRUk9fM5akMbwD6_oI-4RL8=.f6589215-0807-4887-8d52-8a6b33097bfb@github.com>
Message-ID: <4EiAS4FLadSHwpkIFXhnIfKcLkURpa-izj3m0PEMa0Y=.d5cd56fd-1a1a-4827-bfea-4cf8273319d3@github.com>

On Tue, 23 Jan 2024 21:41:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Requested changes
>
> src/java.base/share/classes/java/lang/String.java line 4229:
> 
>> 4227:      *     <th scope="row">{@code \u005Cu...uXXXX}</th>
>> 4228:      *     <td>unicode escape</td>
>> 4229:      *     <td>single character UTF-16 equivalent</td>
> 
> It would be clearer to have "single UTF-16 code unit equivalent" as the translation explanation

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467635554

From jlaskey at openjdk.org  Fri Jan 26 13:14:40 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:14:40 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v9]
In-Reply-To: <Mb7KJbUx0IYaM1Aqe4RjgYlFaZgQAkJIuDFcGIYbh-s=.6fd79cc2-6c5b-4db2-8ef0-1c0c06eaa616@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <4wvO-Q9bbbg4kFD1u3yJSt8aazvW5BP9eLp4epde4AU=.6a27769a-7be9-49ce-af41-d85ed5232c55@github.com>
 <Mb7KJbUx0IYaM1Aqe4RjgYlFaZgQAkJIuDFcGIYbh-s=.6fd79cc2-6c5b-4db2-8ef0-1c0c06eaa616@github.com>
Message-ID: <54BKg2e_G3kl9H5IEHlQFwTPWmcD8VVEOk4-fmgCW1c=.6fcd7c41-efcc-4958-92a5-519d0ea89cac@github.com>

On Fri, 26 Jan 2024 08:38:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update String.java
>
> src/java.base/share/classes/java/lang/String.java line 4238:
> 
>> 4236:      * @return String with escape sequences and unicode escapes translated.
>> 4237:      *
>> 4238:      * @implNote Normally, unicode escapes are translated by the compiler before string
> 
> A minor comment on the implNote is that it better to drop "Normally," from the beginning of this sentence and "However," from the second sentence. I think it would read a bit better.

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467635735

From jlaskey at openjdk.org  Fri Jan 26 13:14:42 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:14:42 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v7]
In-Reply-To: <BBVrlM0S7AIbiv60AyHl51bJgBF6n72ALAfsofM38Vk=.867d8433-e06a-4397-bd1a-6a3b485fd626@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <rcKlB6jaG0Y42hQdSk6rspyvWIVhRnceWC0WKn2wahI=.4298480f-eea4-40c3-a3be-18de0870397e@github.com>
 <BBVrlM0S7AIbiv60AyHl51bJgBF6n72ALAfsofM38Vk=.867d8433-e06a-4397-bd1a-6a3b485fd626@github.com>
Message-ID: <9070OxVRURzIN8jFBdMX1NDisdWei-hqdelQqmcWvMk=.3ae0200b-79d8-4121-91fa-cb8d0750a825@github.com>

On Fri, 19 Jan 2024 18:28:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright
>
> test/jdk/java/lang/String/TranslateEscapes.java line 113:
> 
>> 111:     }
>> 112: 
>> 113:     static void verifyEscape(String string1, String string2) {
> 
> These are unicode escapes too.  The method name should reflect that.

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467635284

From jvernee at openjdk.org  Fri Jan 26 13:22:49 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 26 Jan 2024 13:22:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
Message-ID: <mnVUsWqFW-fh69BqfmEs2dn4ktlMvbGzQkYJAilxTX8=.89fab6a6-3909-4aeb-8e24-1b4dc2e1eeb9@github.com>

On Fri, 26 Jan 2024 09:12:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.

It seems like you could lazily define the aux class when the target class first needs it, instead of eagerly while the target class is being defined. e.g. generate the class bytes for the aux class up front, and embed them in the target class (For instance as a Base64 encoded string, which fits well into the constant pool). Then, have the transformed code in the target class define the the aux class when it is first needed, at which point you do have access to a lookup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1912057333

From jlaskey at openjdk.org  Fri Jan 26 13:28:50 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:28:50 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v10]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <nUGrqXsSZsiSILcJrQya747yStIS8ptcO0aWtM37lAg=.f497f62b-690d-4dc9-b575-d29110020ee6@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

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/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/8fd58b55..f0ea4bc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=08-09

  Stats: 21 lines in 2 files changed: 7 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From jlaskey at openjdk.org  Fri Jan 26 13:38:40 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 13:38:40 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v11]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <vudTRyLDMpHWgdhQe2XqFZXFw9jLpprhc2VtklHhkDI=.41167b01-1c7f-40de-a2ac-fd7da5c07eae@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update unicode to Unicode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/f0ea4bc9..b57a551d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=09-10

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From eirbjo at openjdk.org  Fri Jan 26 14:32:58 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 26 Jan 2024 14:32:58 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v15]
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: <RaU2LyxCHHixKgyfh1og0bkEUXix58O6L3Akf8mmLe4=.9a5882a3-d59a-4c0d-8648-e3f56bea62cc@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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits:

 - Merge branch 'master' into data-descriptor
 - Update comment of expect64BitDataDescriptor to reflect relaxed validation
 - Dial down validation of the Zip64 extra field
 - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp
   
   Co-authored-by: Volodymyr Paprotski <vpaprotski at openjdk.org>
   Reviewed-by: kvn, thartmann, epeter, jbhateja
 - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
   
   Reviewed-by: mbaesken
 - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed
   
   Reviewed-by: mullan, valeriep
 - 8320890: [AIX] Find a better way to mimic dl handle equality
   
   Reviewed-by: stuefe, mdoerr
 - 8323276: StressDirListings.java fails on AIX
   
   Reviewed-by: jpai, dfuchs
 - 8319793: C2 compilation fails with "Bad graph detected in build_loop_late" after JDK-8279888
   
   Reviewed-by: chagedorn, epeter
 - 8314515: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=false i=8 j=0"
   
   Reviewed-by: alanb
 - ... and 218 more: https://git.openjdk.org/jdk/compare/e10d1400...4af7f500

-------------

Changes: https://git.openjdk.org/jdk/pull/12524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=14
  Stats: 335 lines in 2 files changed: 331 ins; 0 del; 4 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 eirbjo at openjdk.org  Fri Jan 26 14:37:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 26 Jan 2024 14:37:40 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v15]
In-Reply-To: <RaU2LyxCHHixKgyfh1og0bkEUXix58O6L3Akf8mmLe4=.9a5882a3-d59a-4c0d-8648-e3f56bea62cc@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <RaU2LyxCHHixKgyfh1og0bkEUXix58O6L3Akf8mmLe4=.9a5882a3-d59a-4c0d-8648-e3f56bea62cc@github.com>
Message-ID: <nfBedT4S_-6UVKnGVpKCL2Ori-yqUCXjvDoETZAPB6o=.8e54cd40-f27a-4f4f-8429-027c9a45c230@github.com>

On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bj?rsn?s <eirbjo 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 AND the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits:
> 
>  - Merge branch 'master' into data-descriptor
>  - Update comment of expect64BitDataDescriptor to reflect relaxed validation
>  - Dial down validation of the Zip64 extra field
>  - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp
>    
>    Co-authored-by: Volodymyr Paprotski <vpaprotski at openjdk.org>
>    Reviewed-by: kvn, thartmann, epeter, jbhateja
>  - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
>    
>    Reviewed-by: mbaesken
>  - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed
>    
>    Reviewed-by: mullan, valeriep
>  - 8320890: [AIX] Find a better way to mimic dl handle equality
>    
>    Reviewed-by: stuefe, mdoerr
>  - 8323276: StressDirListings.java fails on AIX
>    
>    Reviewed-by: jpai, dfuchs
>  - 8319793: C2 compilation fails with "Bad graph detected in build_loop_late" after JDK-8279888
>    
>    Reviewed-by: chagedorn, epeter
>  - 8314515: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=false i=8 j=0"
>    
>    Reviewed-by: alanb
>  - ... and 218 more: https://git.openjdk.org/jdk/compare/e10d1400...4af7f500

In help make progress here, I have relaxed the validation here such that we now check:

- That the "streaming mode" bit 3 flag is set
- That at least one of the LOC's size fields are marked 0xFFFFFFFF.
- That the LOC extra field has a field with header ID 0x1 (Zip64)

Any reading/validation of the contents of the Zip64 extra field has been removed.

@jaikiran Is this closer to what you'd like to see?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1912164693

From jlaskey at openjdk.org  Fri Jan 26 15:06:50 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 15:06:50 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v12]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <HK5D7UREgy9hvR2sKR1wxXJixQG1n4pNnxOCQz0RcDY=.2320aa7a-f1f5-4cea-8a50-cab42cdbd259@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8263261
 - Update unicode to Unicode
 - Requested changes
 - Update String.java
 - Requested changes
 - Update Copyright
 - Update copyright year of test
 - Add JLS Unicode Escapes reference
 - Update comment
 - Update copyright year
 - ... and 2 more: https://git.openjdk.org/jdk/compare/eea3c2d9...040bda82

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/b57a551d..040bda82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=10-11

  Stats: 8261 lines in 340 files changed: 5165 ins; 1908 del; 1188 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From rriggs at openjdk.org  Fri Jan 26 17:04:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Jan 2024 17:04:38 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v12]
In-Reply-To: <HK5D7UREgy9hvR2sKR1wxXJixQG1n4pNnxOCQz0RcDY=.2320aa7a-f1f5-4cea-8a50-cab42cdbd259@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <HK5D7UREgy9hvR2sKR1wxXJixQG1n4pNnxOCQz0RcDY=.2320aa7a-f1f5-4cea-8a50-cab42cdbd259@github.com>
Message-ID: <WYuOUdVth4mi0YCnmYhQxHP5_y6jfuK3lXbaVQevq1U=.7bb0734e-d048-4ddb-9602-4d93fe59bb9b@github.com>

On Fri, 26 Jan 2024 15:06:50 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8263261
>  - Update unicode to Unicode
>  - Requested changes
>  - Update String.java
>  - Requested changes
>  - Update Copyright
>  - Update copyright year of test
>  - Add JLS Unicode Escapes reference
>  - Update comment
>  - Update copyright year
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b94b04ff...040bda82

src/java.base/share/classes/java/lang/String.java line 4229:

> 4227:      *     <th scope="row">{@code \u005Cu...uXXXX}</th>
> 4228:      *     <td>Unicode escape</td>
> 4229:      *     <td>single UTF-16 code unit equivalent</td>

The `...` makes it less clear what is being shown.  It might be clearer to include the XXXX in the resulting value and drop the multiple `u` case.

src/java.base/share/classes/java/lang/String.java line 4245:

> 4243:      * escape sequences and Unicode escapes are translated as encountered in one pass and
> 4244:      * <strong>not</strong> done as an Unicode escapes pass followed by an escape sequences
> 4245:      * pass.

I would move the description of the compiler behavior to the end and remove "also". For example, 
Suggestion:

     * @implNote As a convenience for use with constructed
     * strings, this method translates Unicode escapes. For example, this
     * method could be used when ASCII encoded text files need to maintain Unicode
     * content. The translation is done in a single pass and is non-recursive. That is,
     * escape sequences and Unicode escapes are translated as encountered in one pass and
     * <strong>not</strong> done as an Unicode escapes pass followed by an escape sequences
     * pass. By comparison, the compiler translates all Unicode escapes before string
     * literals are translated.

test/jdk/java/lang/String/TranslateEscapes.java line 97:

> 95:         verifyUnicodeEscape("\\u2022", "\u2022");
> 96:         verifyUnicodeEscape("\\ud83c\\udf09", "\ud83c\udf09");
> 97:         verifyUnicodeEscape("\\uuuuu2022", "\uuuuu2022");

Include the code from the example as a test case too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467892757
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467895901
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467900516

From duke at openjdk.org  Fri Jan 26 17:22:30 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 26 Jan 2024 17:22:30 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@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>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
Message-ID: <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>

On Thu, 18 Jan 2024 21:36:22 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> 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
> ...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run the benchmarking of new DQPS in your environment with AVX?
> 
> Take all classes below and put them in the package org.openjdk.bench.java.util.
> ArraysSort class contains all tests for the new versions and ready to use.
> (it will run all tests in one execution).
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
> 
> Many thanks,
> Vladimir

Hi Vladimir (@iaroslavski),

Please see the JMH data below.

Thanks,
Vamsi

Benchmark              (builder)   (size)  Mode  Cnt       Score      Error  Units
ArraysSort.Int.a15        RANDOM      600  avgt    4       7.096 ?    0.081  us/op
ArraysSort.Int.a15        RANDOM     2000  avgt    4      44.014 ?    1.717  us/op
ArraysSort.Int.a15        RANDOM    90000  avgt    4    4451.444 ?   71.168  us/op
ArraysSort.Int.a15        RANDOM   400000  avgt    4   22751.966 ?  683.597  us/op
ArraysSort.Int.a15        RANDOM  3000000  avgt    4  190326.306 ? 8008.512  us/op
ArraysSort.Int.a15      REPEATED      600  avgt    4       1.044 ?    0.016  us/op
ArraysSort.Int.a15      REPEATED     2000  avgt    4       2.272 ?    0.287  us/op
ArraysSort.Int.a15      REPEATED    90000  avgt    4     412.331 ?   11.656  us/op
ArraysSort.Int.a15      REPEATED   400000  avgt    4    1908.978 ?   30.241  us/op
ArraysSort.Int.a15      REPEATED  3000000  avgt    4   15163.443 ?  100.425  us/op
ArraysSort.Int.a15       STAGGER      600  avgt    4       1.055 ?    0.057  us/op
ArraysSort.Int.a15       STAGGER     2000  avgt    4       3.408 ?    0.096  us/op
ArraysSort.Int.a15       STAGGER    90000  avgt    4     149.220 ?    4.022  us/op
ArraysSort.Int.a15       STAGGER   400000  avgt    4     663.096 ?   30.252  us/op
ArraysSort.Int.a15       STAGGER  3000000  avgt    4    5206.890 ?  234.857  us/op
ArraysSort.Int.a15       SHUFFLE      600  avgt    4       4.611 ?    0.118  us/op
ArraysSort.Int.a15       SHUFFLE     2000  avgt    4      17.955 ?    0.356  us/op
ArraysSort.Int.a15       SHUFFLE    90000  avgt    4    1410.357 ?   41.128  us/op
ArraysSort.Int.a15       SHUFFLE   400000  avgt    4    5739.311 ?  128.270  us/op
ArraysSort.Int.a15       SHUFFLE  3000000  avgt    4   41501.980 ?  829.443  us/op
ArraysSort.Int.jdk        RANDOM      600  avgt    4       1.612 ?    0.088  us/op
ArraysSort.Int.jdk        RANDOM     2000  avgt    4       6.893 ?    0.375  us/op
ArraysSort.Int.jdk        RANDOM    90000  avgt    4     522.749 ?   19.386  us/op
ArraysSort.Int.jdk        RANDOM   400000  avgt    4    2424.204 ?   63.844  us/op
ArraysSort.Int.jdk        RANDOM  3000000  avgt    4   21000.434 ?  801.315  us/op
ArraysSort.Int.jdk      REPEATED      600  avgt    4       0.496 ?    0.030  us/op
ArraysSort.Int.jdk      REPEATED     2000  avgt    4       1.037 ?    0.083  us/op
ArraysSort.Int.jdk      REPEATED    90000  avgt    4      57.763 ?    1.955  us/op
ArraysSort.Int.jdk      REPEATED   400000  avgt    4     182.238 ?   12.629  us/op
ArraysSort.Int.jdk      REPEATED  3000000  avgt    4    1708.082 ?  159.046  us/op
ArraysSort.Int.jdk       STAGGER      600  avgt    4       1.038 ?    0.062  us/op
ArraysSort.Int.jdk       STAGGER     2000  avgt    4       3.434 ?    0.195  us/op
ArraysSort.Int.jdk       STAGGER    90000  avgt    4     148.638 ?    2.531  us/op
ArraysSort.Int.jdk       STAGGER   400000  avgt    4     663.076 ?   14.137  us/op
ArraysSort.Int.jdk       STAGGER  3000000  avgt    4    5212.821 ?  142.427  us/op
ArraysSort.Int.jdk       SHUFFLE      600  avgt    4       1.926 ?    0.116  us/op
ArraysSort.Int.jdk       SHUFFLE     2000  avgt    4       6.858 ?    0.135  us/op
ArraysSort.Int.jdk       SHUFFLE    90000  avgt    4     473.441 ?   21.678  us/op
ArraysSort.Int.jdk       SHUFFLE   400000  avgt    4    2153.779 ?   71.683  us/op
ArraysSort.Int.jdk       SHUFFLE  3000000  avgt    4   18180.141 ?  691.292  us/op
ArraysSort.Int.p_a15      RANDOM      600  avgt    4       7.102 ?    0.058  us/op
ArraysSort.Int.p_a15      RANDOM     2000  avgt    4      43.708 ?    1.933  us/op
ArraysSort.Int.p_a15      RANDOM    90000  avgt    4     743.725 ?  144.927  us/op
ArraysSort.Int.p_a15      RANDOM   400000  avgt    4    3099.628 ?   59.222  us/op
ArraysSort.Int.p_a15      RANDOM  3000000  avgt    4   25830.847 ? 1998.651  us/op
ArraysSort.Int.p_a15    REPEATED      600  avgt    4       1.042 ?    0.035  us/op
ArraysSort.Int.p_a15    REPEATED     2000  avgt    4       2.273 ?    0.117  us/op
ArraysSort.Int.p_a15    REPEATED    90000  avgt    4     204.887 ?   12.250  us/op
ArraysSort.Int.p_a15    REPEATED   400000  avgt    4     758.837 ?   37.845  us/op
ArraysSort.Int.p_a15    REPEATED  3000000  avgt    4    7635.330 ? 8220.782  us/op
ArraysSort.Int.p_a15     STAGGER      600  avgt    4       1.045 ?    0.046  us/op
ArraysSort.Int.p_a15     STAGGER     2000  avgt    4       3.410 ?    0.082  us/op
ArraysSort.Int.p_a15     STAGGER    90000  avgt    4      88.093 ?    7.805  us/op
ArraysSort.Int.p_a15     STAGGER   400000  avgt    4     218.848 ?   48.536  us/op
ArraysSort.Int.p_a15     STAGGER  3000000  avgt    4    2245.299 ?   77.811  us/op
ArraysSort.Int.p_a15     SHUFFLE      600  avgt    4       4.594 ?    0.165  us/op
ArraysSort.Int.p_a15     SHUFFLE     2000  avgt    4      17.759 ?    0.608  us/op
ArraysSort.Int.p_a15     SHUFFLE    90000  avgt    4     293.962 ?   49.226  us/op
ArraysSort.Int.p_a15     SHUFFLE   400000  avgt    4    1017.350 ?  181.660  us/op
ArraysSort.Int.p_a15     SHUFFLE  3000000  avgt    4    7419.434 ? 6051.411  us/op
ArraysSort.Int.p_jdk      RANDOM      600  avgt    4       1.815 ?    0.628  us/op
ArraysSort.Int.p_jdk      RANDOM     2000  avgt    4       6.923 ?    0.644  us/op
ArraysSort.Int.p_jdk      RANDOM    90000  avgt    4     266.333 ?   39.212  us/op
ArraysSort.Int.p_jdk      RANDOM   400000  avgt    4     835.310 ?  107.797  us/op
ArraysSort.Int.p_jdk      RANDOM  3000000  avgt    4    6090.584 ? 3322.954  us/op
ArraysSort.Int.p_jdk    REPEATED      600  avgt    4       0.486 ?    0.016  us/op
ArraysSort.Int.p_jdk    REPEATED     2000  avgt    4       1.091 ?    0.181  us/op
ArraysSort.Int.p_jdk    REPEATED    90000  avgt    4     104.197 ?   18.755  us/op
ArraysSort.Int.p_jdk    REPEATED   400000  avgt    4     230.945 ?   45.924  us/op
ArraysSort.Int.p_jdk    REPEATED  3000000  avgt    4    3781.371 ? 8241.887  us/op
ArraysSort.Int.p_jdk     STAGGER      600  avgt    4       1.046 ?    0.045  us/op
ArraysSort.Int.p_jdk     STAGGER     2000  avgt    4       3.405 ?    0.195  us/op
ArraysSort.Int.p_jdk     STAGGER    90000  avgt    4      77.708 ?    9.312  us/op
ArraysSort.Int.p_jdk     STAGGER   400000  avgt    4     215.360 ?   25.983  us/op
ArraysSort.Int.p_jdk     STAGGER  3000000  avgt    4    2256.305 ?  103.960  us/op
ArraysSort.Int.p_jdk     SHUFFLE      600  avgt    4       1.952 ?    0.106  us/op
ArraysSort.Int.p_jdk     SHUFFLE     2000  avgt    4       6.962 ?    0.970  us/op
ArraysSort.Int.p_jdk     SHUFFLE    90000  avgt    4     165.546 ?   31.007  us/op
ArraysSort.Int.p_jdk     SHUFFLE   400000  avgt    4     434.846 ?  118.886  us/op
ArraysSort.Int.p_jdk     SHUFFLE  3000000  avgt    4    4351.851 ? 2555.203  us/op
ArraysSort.Int.p_r20p     RANDOM      600  avgt    4       4.315 ?    0.095  us/op
ArraysSort.Int.p_r20p     RANDOM     2000  avgt    4      20.322 ?    1.816  us/op
ArraysSort.Int.p_r20p     RANDOM    90000  avgt    4     409.892 ?   54.227  us/op
ArraysSort.Int.p_r20p     RANDOM   400000  avgt    4    1322.129 ?   64.913  us/op
ArraysSort.Int.p_r20p     RANDOM  3000000  avgt    4    9790.138 ? 1686.701  us/op
ArraysSort.Int.p_r20p   REPEATED      600  avgt    4       1.033 ?    0.091  us/op
ArraysSort.Int.p_r20p   REPEATED     2000  avgt    4       3.247 ?    0.488  us/op
ArraysSort.Int.p_r20p   REPEATED    90000  avgt    4     184.565 ?   13.426  us/op
ArraysSort.Int.p_r20p   REPEATED   400000  avgt    4     745.817 ?   75.773  us/op
ArraysSort.Int.p_r20p   REPEATED  3000000  avgt    4    5881.615 ?  373.430  us/op
ArraysSort.Int.p_r20p    STAGGER      600  avgt    4       0.807 ?    0.008  us/op
ArraysSort.Int.p_r20p    STAGGER     2000  avgt    4       2.733 ?    0.085  us/op
ArraysSort.Int.p_r20p    STAGGER    90000  avgt    4      73.869 ?    6.061  us/op
ArraysSort.Int.p_r20p    STAGGER   400000  avgt    4     208.361 ?   28.714  us/op
ArraysSort.Int.p_r20p    STAGGER  3000000  avgt    4    2122.314 ?  174.260  us/op
ArraysSort.Int.p_r20p    SHUFFLE      600  avgt    4       3.386 ?    0.017  us/op
ArraysSort.Int.p_r20p    SHUFFLE     2000  avgt    4      11.570 ?    0.225  us/op
ArraysSort.Int.p_r20p    SHUFFLE    90000  avgt    4     146.273 ?   14.723  us/op
ArraysSort.Int.p_r20p    SHUFFLE   400000  avgt    4     766.287 ?   48.840  us/op
ArraysSort.Int.p_r20p    SHUFFLE  3000000  avgt    4    5917.997 ?  366.976  us/op
ArraysSort.Int.p_r20s     RANDOM      600  avgt    4       4.334 ?    0.220  us/op
ArraysSort.Int.p_r20s     RANDOM     2000  avgt    4      23.553 ?   13.608  us/op
ArraysSort.Int.p_r20s     RANDOM    90000  avgt    4     818.752 ?   81.659  us/op
ArraysSort.Int.p_r20s     RANDOM   400000  avgt    4    2817.805 ?  521.352  us/op
ArraysSort.Int.p_r20s     RANDOM  3000000  avgt    4   21512.458 ? 2113.741  us/op
ArraysSort.Int.p_r20s   REPEATED      600  avgt    4       1.048 ?    0.134  us/op
ArraysSort.Int.p_r20s   REPEATED     2000  avgt    4       3.207 ?    0.324  us/op
ArraysSort.Int.p_r20s   REPEATED    90000  avgt    4     183.860 ?   21.690  us/op
ArraysSort.Int.p_r20s   REPEATED   400000  avgt    4     769.766 ?   53.749  us/op
ArraysSort.Int.p_r20s   REPEATED  3000000  avgt    4    5883.943 ?  331.089  us/op
ArraysSort.Int.p_r20s    STAGGER      600  avgt    4       0.796 ?    0.009  us/op
ArraysSort.Int.p_r20s    STAGGER     2000  avgt    4       2.709 ?    0.096  us/op
ArraysSort.Int.p_r20s    STAGGER    90000  avgt    4      74.508 ?    8.668  us/op
ArraysSort.Int.p_r20s    STAGGER   400000  avgt    4     209.745 ?   22.114  us/op
ArraysSort.Int.p_r20s    STAGGER  3000000  avgt    4    2129.720 ?  343.004  us/op
ArraysSort.Int.p_r20s    SHUFFLE      600  avgt    4       3.394 ?    0.267  us/op
ArraysSort.Int.p_r20s    SHUFFLE     2000  avgt    4      11.304 ?    0.890  us/op
ArraysSort.Int.p_r20s    SHUFFLE    90000  avgt    4     277.046 ?   37.713  us/op
ArraysSort.Int.p_r20s    SHUFFLE   400000  avgt    4     845.203 ?  113.387  us/op
ArraysSort.Int.p_r20s    SHUFFLE  3000000  avgt    4    6028.514 ?  859.545  us/op
ArraysSort.Int.r20p       RANDOM      600  avgt    4       4.343 ?    0.276  us/op
ArraysSort.Int.r20p       RANDOM     2000  avgt    4      20.323 ?    2.063  us/op
ArraysSort.Int.r20p       RANDOM    90000  avgt    4    4073.793 ?   69.464  us/op
ArraysSort.Int.r20p       RANDOM   400000  avgt    4   19768.316 ?  499.096  us/op
ArraysSort.Int.r20p       RANDOM  3000000  avgt    4  165296.770 ? 1527.047  us/op
ArraysSort.Int.r20p     REPEATED      600  avgt    4       1.048 ?    0.157  us/op
ArraysSort.Int.r20p     REPEATED     2000  avgt    4       3.212 ?    0.314  us/op
ArraysSort.Int.r20p     REPEATED    90000  avgt    4     410.775 ?   12.550  us/op
ArraysSort.Int.r20p     REPEATED   400000  avgt    4    1869.529 ?   21.372  us/op
ArraysSort.Int.r20p     REPEATED  3000000  avgt    4   14302.261 ?  177.065  us/op
ArraysSort.Int.r20p      STAGGER      600  avgt    4       0.808 ?    0.106  us/op
ArraysSort.Int.r20p      STAGGER     2000  avgt    4       2.683 ?    0.106  us/op
ArraysSort.Int.r20p      STAGGER    90000  avgt    4     121.519 ?    1.758  us/op
ArraysSort.Int.r20p      STAGGER   400000  avgt    4     548.277 ?   20.543  us/op
ArraysSort.Int.r20p      STAGGER  3000000  avgt    4    4496.204 ?  287.544  us/op
ArraysSort.Int.r20p      SHUFFLE      600  avgt    4       3.383 ?    0.105  us/op
ArraysSort.Int.r20p      SHUFFLE     2000  avgt    4      11.400 ?    1.032  us/op
ArraysSort.Int.r20p      SHUFFLE    90000  avgt    4    1001.561 ?   59.738  us/op
ArraysSort.Int.r20p      SHUFFLE   400000  avgt    4    4667.466 ?  179.177  us/op
ArraysSort.Int.r20p      SHUFFLE  3000000  avgt    4   36284.178 ? 1077.830  us/op
ArraysSort.Int.r20s       RANDOM      600  avgt    4       4.490 ?    0.093  us/op
ArraysSort.Int.r20s       RANDOM     2000  avgt    4      21.156 ?    2.385  us/op
ArraysSort.Int.r20s       RANDOM    90000  avgt    4    4103.675 ?   77.981  us/op
ArraysSort.Int.r20s       RANDOM   400000  avgt    4   19946.442 ?  399.865  us/op
ArraysSort.Int.r20s       RANDOM  3000000  avgt    4  164962.433 ? 2493.795  us/op
ArraysSort.Int.r20s     REPEATED      600  avgt    4       1.056 ?    0.125  us/op
ArraysSort.Int.r20s     REPEATED     2000  avgt    4       3.230 ?    0.490  us/op
ArraysSort.Int.r20s     REPEATED    90000  avgt    4     412.847 ?   13.513  us/op
ArraysSort.Int.r20s     REPEATED   400000  avgt    4    1870.414 ?   24.559  us/op
ArraysSort.Int.r20s     REPEATED  3000000  avgt    4   14267.288 ?  136.736  us/op
ArraysSort.Int.r20s      STAGGER      600  avgt    4       0.796 ?    0.025  us/op
ArraysSort.Int.r20s      STAGGER     2000  avgt    4       2.747 ?    0.080  us/op
ArraysSort.Int.r20s      STAGGER    90000  avgt    4     125.870 ?    6.901  us/op
ArraysSort.Int.r20s      STAGGER   400000  avgt    4     535.893 ?   24.697  us/op
ArraysSort.Int.r20s      STAGGER  3000000  avgt    4    4475.088 ?  105.652  us/op
ArraysSort.Int.r20s      SHUFFLE      600  avgt    4       3.353 ?    0.205  us/op
ArraysSort.Int.r20s      SHUFFLE     2000  avgt    4      11.682 ?    0.735  us/op
ArraysSort.Int.r20s      SHUFFLE    90000  avgt    4    1001.254 ?   56.068  us/op
ArraysSort.Int.r20s      SHUFFLE   400000  avgt    4    4702.312 ?  270.761  us/op
ArraysSort.Int.r20s      SHUFFLE  3000000  avgt    4   35414.307 ?  169.534  us/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1912409725

From jlaskey at openjdk.org  Fri Jan 26 17:36:52 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 17:36:52 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v13]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

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/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/040bda82..74707a66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=11-12

  Stats: 13 lines in 1 file changed: 5 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From jlaskey at openjdk.org  Fri Jan 26 17:36:56 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 Jan 2024 17:36:56 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v12]
In-Reply-To: <WYuOUdVth4mi0YCnmYhQxHP5_y6jfuK3lXbaVQevq1U=.7bb0734e-d048-4ddb-9602-4d93fe59bb9b@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <HK5D7UREgy9hvR2sKR1wxXJixQG1n4pNnxOCQz0RcDY=.2320aa7a-f1f5-4cea-8a50-cab42cdbd259@github.com>
 <WYuOUdVth4mi0YCnmYhQxHP5_y6jfuK3lXbaVQevq1U=.7bb0734e-d048-4ddb-9602-4d93fe59bb9b@github.com>
Message-ID: <9k6_P05u0XSf54mpjFSxdF4-MMewG-H0XQnOiHq60LQ=.65425d8a-8780-40a1-a428-646dcadaf0a5@github.com>

On Fri, 26 Jan 2024 16:54:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8263261
>>  - Update unicode to Unicode
>>  - Requested changes
>>  - Update String.java
>>  - Requested changes
>>  - Update Copyright
>>  - Update copyright year of test
>>  - Add JLS Unicode Escapes reference
>>  - Update comment
>>  - Update copyright year
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/af9bfd62...040bda82
>
> src/java.base/share/classes/java/lang/String.java line 4229:
> 
>> 4227:      *     <th scope="row">{@code \u005Cu...uXXXX}</th>
>> 4228:      *     <td>Unicode escape</td>
>> 4229:      *     <td>single UTF-16 code unit equivalent</td>
> 
> The `...` makes it less clear what is being shown.  It might be clearer to include the XXXX in the resulting value and drop the multiple `u` case.

Changed

> src/java.base/share/classes/java/lang/String.java line 4245:
> 
>> 4243:      * escape sequences and Unicode escapes are translated as encountered in one pass and
>> 4244:      * <strong>not</strong> done as an Unicode escapes pass followed by an escape sequences
>> 4245:      * pass.
> 
> I would move the description of the compiler behavior to the end and remove "also". For example, 
> Suggestion:
> 
>      * @implNote As a convenience for use with constructed
>      * strings, this method translates Unicode escapes. For example, this
>      * method could be used when ASCII encoded text files need to maintain Unicode
>      * content. The translation is done in a single pass and is non-recursive. That is,
>      * escape sequences and Unicode escapes are translated as encountered in one pass and
>      * <strong>not</strong> done as an Unicode escapes pass followed by an escape sequences
>      * pass. By comparison, the compiler translates all Unicode escapes before string
>      * literals are translated.

Changed

> test/jdk/java/lang/String/TranslateEscapes.java line 97:
> 
>> 95:         verifyUnicodeEscape("\\u2022", "\u2022");
>> 96:         verifyUnicodeEscape("\\ud83c\\udf09", "\ud83c\udf09");
>> 97:         verifyUnicodeEscape("\\uuuuu2022", "\uuuuu2022");
> 
> Include the code from the example as a test case too.

None present. Was a mis-paste.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467926349
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467926483
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1467929023

From abimpoudis at openjdk.org  Fri Jan 26 18:02:58 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 26 Jan 2024 18:02:58 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@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 redundant null check  and introduce a const boolean for unconditionally exact pairs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/854c20a1..e466cfba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=53-54

  Stats: 12 lines in 1 file changed: 0 ins; 9 del; 3 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 vromero at openjdk.org  Fri Jan 26 18:33:22 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Jan 2024 18:33:22 GMT
Subject: RFR: 8323835: Updating ASM to 9.6 for JDK 23
In-Reply-To: <ovgeQL_IV6Vp_aflZlETvJAzimwExyloakAqyDGth0s=.e450fc46-9eb8-4ef7-b10d-cefa8f3e3310@github.com>
References: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
 <ovgeQL_IV6Vp_aflZlETvJAzimwExyloakAqyDGth0s=.e450fc46-9eb8-4ef7-b10d-cefa8f3e3310@github.com>
Message-ID: <KbsGxB30Ljz7WvkQtcyGx3PIcaEUajkXtLjD-RbU30o=.d34d97a2-a37b-426d-86b3-c956c3a3183a@github.com>

On Fri, 26 Jan 2024 01:36:47 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Looks okay to me. I would rely on your testing for verification.

I have run tier1-6 tests, they look OK

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17453#issuecomment-1912506728

From vromero at openjdk.org  Fri Jan 26 18:37:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Jan 2024 18:37:42 GMT
Subject: Integrated: 8323835: Updating ASM to 9.6 for JDK 23
In-Reply-To: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
References: <hANua3u83o-G5O4p49o3aT013rFGQIMBFPy52NARj_s=.0c27f97a-c513-49f8-8c54-86bac561a4d9@github.com>
Message-ID: <idHoUMZ2zpugu_sOv8mkls45wMHQ1yK2TRU-JQoT7WM=.d3ec490b-7037-4ec4-9254-c5ce093e0db8@github.com>

On Tue, 16 Jan 2024 21:18:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Updating ASM to version 9.6,
> 
> Thanks in advance for the reviews,
> Vicente

This pull request has now been integrated.

Changeset: 91d8ea79
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91d8ea79d947aa7dad91d8ed550ed34a7d49d885
Stats:     1536 lines in 127 files changed: 1033 ins; 181 del; 322 mod

8323835: Updating ASM to 9.6 for JDK 23

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/17453

From duke at openjdk.org  Fri Jan 26 19:00:40 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Fri, 26 Jan 2024 19:00:40 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@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>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
Message-ID: <QpEHYExcKZF8BrAKdaPG3t5_f8YLzhV6l8_TMmFDIfI=.8622371c-108d-4eeb-8e5f-df66a9dd83c2@github.com>

On Fri, 26 Jan 2024 17:19:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run the benchmarking of new DQPS in your environment with AVX?
>> 
>> Take all classes below and put them in the package org.openjdk.bench.java.util.
>> ArraysSort class contains all tests for the new versions and ready to use.
>> (it will run all tests in one execution).
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
>> 
>> Many thanks,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the JMH data below.
> 
> Thanks,
> Vamsi
> 
> Benchmark              (builder)   (size)  Mode  Cnt       Score      Error  Units
> ArraysSort.Int.a15        RANDOM      600  avgt    4       7.096 ?    0.081  us/op
> ArraysSort.Int.a15        RANDOM     2000  avgt    4      44.014 ?    1.717  us/op
> ArraysSort.Int.a15        RANDOM    90000  avgt    4    4451.444 ?   71.168  us/op
> ArraysSort.Int.a15        RANDOM   400000  avgt    4   22751.966 ?  683.597  us/op
> ArraysSort.Int.a15        RANDOM  3000000  avgt    4  190326.306 ? 8008.512  us/op
> ArraysSort.Int.a15      REPEATED      600  avgt    4       1.044 ?    0.016  us/op
> ArraysSort.Int.a15      REPEATED     2000  avgt    4       2.272 ?    0.287  us/op
> ArraysSort.Int.a15      REPEATED    90000  avgt    4     412.331 ?   11.656  us/op
> ArraysSort.Int.a15      REPEATED   400000  avgt    4    1908.978 ?   30.241  us/op
> ArraysSort.Int.a15      REPEATED  3000000  avgt    4   15163.443 ?  100.425  us/op
> ArraysSort.Int.a15       STAGGER      600  avgt    4       1.055 ?    0.057  us/op
> ArraysSort.Int.a15       STAGGER     2000  avgt    4       3.408 ?    0.096  us/op
> ArraysSort.Int.a15       STAGGER    90000  avgt    4     149.220 ?    4.022  us/op
> ArraysSort.Int.a15       STAGGER   400000  avgt    4     663.096 ?   30.252  us/op
> ArraysSort.Int.a15       STAGGER  3000000  avgt    4    5206.890 ?  234.857  us/op
> ArraysSort.Int.a15       SHUFFLE      600  avgt    4       4.611 ?    0.118  us/op
> ArraysSort.Int.a15       SHUFFLE     2000  avgt    4      17.955 ?    0.356  us/op
> ArraysSort.Int.a15       SHUFFLE    90000  avgt    4    1410.357 ?   41.128  us/op
> ArraysSort.Int.a15       SHUFFLE   400000  avgt    4    5739.311 ?  128.270  us/op
> ArraysSort.Int.a15       SHUFFLE  3000000  avgt    4   41501.980 ?  829.443  us/op
> ArraysSort.Int.jdk        RANDOM      600  avgt    4       1.612 ?    0.088  us/op
> ArraysSort.Int.jdk        RANDOM     2000  avgt    4       6.893 ?    0.375  us/op
> ArraysSort.Int.jdk        RANDOM    90000  avgt    4     522.749 ?   19.386  us/op
> ArraysSort.Int.jdk        RANDOM   400000  avgt    4    2424.204 ?   63.844  us/op
> ArraysSort.Int.jdk        RANDOM  3000000  avgt    4   21000.434 ?  801.315  us/op
> ArraysSort.Int.jdk      REPEATED      600  avgt    4       0.496 ?    0.030  us/op
> ArraysSort.Int.jdk      REPEATED     2000  avgt    4       1.037 ?    0.083  us/op
> ArraysSort.Int.jdk      REPEATED    90000  avgt    4      57.763 ?    1.955  us/op
> ArraysSort.Int.jd...

Thank you, Vamsi (@vamsi-parasa)!

I will convert the data to more readable format.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1912541236

From jlu at openjdk.org  Fri Jan 26 19:02:29 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jan 2024 19:02:29 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
Message-ID: <xKD1UBG7WEYbWTeTFGMmFTpAAfceEkhI_VAGfGSfovI=.037e1858-0630-4672-9cb5-e11a71e562f9@github.com>

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MessageFormat.toPattern() @implNote to @implSpec.

Hi Archie,

I wasn't sure if you were waiting to make additional changes or something else, but you can go ahead and re-finalize the CSR (when you are ready), now that it has been reviewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1912543193

From acobbs at openjdk.org  Fri Jan 26 19:22:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 19:22:35 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <xKD1UBG7WEYbWTeTFGMmFTpAAfceEkhI_VAGfGSfovI=.037e1858-0630-4672-9cb5-e11a71e562f9@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <xKD1UBG7WEYbWTeTFGMmFTpAAfceEkhI_VAGfGSfovI=.037e1858-0630-4672-9cb5-e11a71e562f9@github.com>
Message-ID: <2Uqr1UFSliWOb8Vx9xq8bDFjbBtm3FF2oUwjm7QY8rQ=.1354c971-c101-4014-99b0-3b7dc868a5f1@github.com>

On Fri, 26 Jan 2024 18:58:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

> I wasn't sure if you were waiting to make additional changes or something else, but you can go ahead and re-finalize the CSR (when you are ready), now that it has been reviewed.

Thanks - I wasn't sure about that. I've updated it now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1912570659

From coleenp at openjdk.org  Fri Jan 26 20:13:59 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Jan 2024 20:13:59 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native
 code files
Message-ID: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>

This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments or strings to just null.  If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.

Ran tier1-4 testing.

-------------

Commit messages:
 - 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files

Changes: https://git.openjdk.org/jdk/pull/17593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324681
  Stats: 8196 lines in 750 files changed: 0 ins; 7 del; 8189 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

PR: https://git.openjdk.org/jdk/pull/17593

From coleenp at openjdk.org  Fri Jan 26 20:26:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Jan 2024 20:26:17 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v2]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <PbzyegOH2TUSVKKVvD9PML-UJHLl96T8lBOH9OlwauI=.37fc9598-4354-4b4d-a573-e3b8801d2fb5@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments or strings to just null.  If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix the comments to "null"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/079b8931..e15a3a0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=00-01

  Stats: 229 lines in 103 files changed: 0 ins; 0 del; 229 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

PR: https://git.openjdk.org/jdk/pull/17593

From lancea at openjdk.org  Fri Jan 26 20:52:44 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 26 Jan 2024 20:52:44 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v15]
In-Reply-To: <nfBedT4S_-6UVKnGVpKCL2Ori-yqUCXjvDoETZAPB6o=.8e54cd40-f27a-4f4f-8429-027c9a45c230@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <RaU2LyxCHHixKgyfh1og0bkEUXix58O6L3Akf8mmLe4=.9a5882a3-d59a-4c0d-8648-e3f56bea62cc@github.com>
 <nfBedT4S_-6UVKnGVpKCL2Ori-yqUCXjvDoETZAPB6o=.8e54cd40-f27a-4f4f-8429-027c9a45c230@github.com>
Message-ID: <5B5-e-8xUHT4BW8Fl_uVwY7QYeuHblLj1Y1j48HokjI=.02468581-c036-4a97-88e1-f24a536a3962@github.com>

On Fri, 26 Jan 2024 14:34:39 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> To help make progress here, I have relaxed the validation such that we now check:
> 
> * That the "streaming mode" bit 3 flag is set
> * That at least one of the LOC's size fields are marked 0xFFFFFFFF.
> * That the LOC extra field has a field with header ID 0x1 (Zip64)
> 
> Any reading/validation of the contents of the Zip64 extra field has been removed.
> 
> @jaikiran Is this closer to what you'd like to see?

Have not forgotten this, hope to get to it next week

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1912678510

From rriggs at openjdk.org  Fri Jan 26 20:54:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Jan 2024 20:54:27 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
Message-ID: <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MessageFormat.toPattern() @implNote to @implSpec.

src/java.base/share/classes/java/text/MessageFormat.java line 558:

> 556:      * @implSpec The implementation in {@link MessageFormat} returns a string
> 557:      * that can be used to create a new instance that is semantically equivalent
> 558:      * to this instance.

The "can be used to create" seems conditional. Perhaps it can be worded as an assertion that can be tested.
Suggestion:

     * @implSpec A new MessageFormat created from the string returned from the implementation of 
     * `MessageFormat.toPattern()` is semantically equivalent to this instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468118990

From coleenp at openjdk.org  Fri Jan 26 21:06:00 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Jan 2024 21:06:00 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v3]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments or strings to just null.  If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix nullptr only contained in strings.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/e15a3a0b..33786c7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=01-02

  Stats: 19 lines in 3 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

PR: https://git.openjdk.org/jdk/pull/17593

From acobbs at openjdk.org  Fri Jan 26 21:19:45 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 21:19:45 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
Message-ID: <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>

On Fri, 26 Jan 2024 20:30:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The "can be used to create" seems conditional. 

It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words.

But I also understand how it comes across as a bit wishy-washy...

Hmm, what do you think about this wording?


@implSpec The implementation in {@link MessageFormat} returns a string that,
when passed to the {@link MessageFormat(String)} constructor, produces an
instance that is semantically equivalent to this instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468155069

From jlu at openjdk.org  Fri Jan 26 21:31:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jan 2024 21:31:37 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
 <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>
Message-ID: <NUM4BtCgx6_ZiD6lYyOKU3naHpmmx20gRIFXz96HW-A=.3ce6bf5b-5f90-4210-bd04-81e177653dfd@github.com>

On Fri, 26 Jan 2024 21:16:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 558:
>> 
>>> 556:      * @implSpec The implementation in {@link MessageFormat} returns a string
>>> 557:      * that can be used to create a new instance that is semantically equivalent
>>> 558:      * to this instance.
>> 
>> The "can be used to create" seems conditional. Perhaps it can be worded as an assertion that can be tested.
>> Suggestion:
>> 
>>      * @implSpec A new MessageFormat created from the string returned from the implementation of 
>>      * `MessageFormat.toPattern()` is semantically equivalent to this instance.
>
>> The "can be used to create" seems conditional. 
> 
> It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words.
> 
> But I also understand how it comes across as a bit wishy-washy...
> 
> Hmm, what do you think about this wording?
> 
> 
> @implSpec The implementation in {@link MessageFormat} returns a string that,
> when passed to the {@link MessageFormat(String)} constructor, produces an
> instance that is semantically equivalent to this instance.

Not sure which wording will ultimately be used, but if the wording ends up including the constructor, it's probably worth mentioning the `applyPattern` method as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468163934

From acobbs at openjdk.org  Fri Jan 26 21:40:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 21:40:35 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v5]
In-Reply-To: <NUM4BtCgx6_ZiD6lYyOKU3naHpmmx20gRIFXz96HW-A=.3ce6bf5b-5f90-4210-bd04-81e177653dfd@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
 <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>
 <NUM4BtCgx6_ZiD6lYyOKU3naHpmmx20gRIFXz96HW-A=.3ce6bf5b-5f90-4210-bd04-81e177653dfd@github.com>
Message-ID: <PxKkpt_w1w9NOpZM5ki20-J6-s9091Es9RcvJPa63i4=.13559259-8d97-45bc-83f7-fbd72c375689@github.com>

On Fri, 26 Jan 2024 21:28:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>> The "can be used to create" seems conditional. 
>> 
>> It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words.
>> 
>> But I also understand how it comes across as a bit wishy-washy...
>> 
>> Hmm, what do you think about this wording?
>> 
>> 
>> @implSpec The implementation in {@link MessageFormat} returns a string that,
>> when passed to the {@link MessageFormat(String)} constructor, produces an
>> instance that is semantically equivalent to this instance.
>
> Not sure which wording will ultimately be used, but if the wording ends up including the constructor, it's probably worth mentioning the `applyPattern` method as well.

Good point... maybe this?

@implSpec The implementation in {@link MessageFormat} returns a string that, when passed
to a {@code MessageFormat()} constructor or {@link #applyPattern applyPattern()}, produces
an instance that is semantically equivalent to this instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468170808

From dcubed at openjdk.org  Fri Jan 26 22:05:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 26 Jan 2024 22:05:10 GMT
Subject: Integrated: 8324786: validate-source fails after JDK-8042981
Message-ID: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>

A trivial fix for validate-source.

-------------

Commit messages:
 - 8324786: validate-source fails after JDK-8042981

Changes: https://git.openjdk.org/jdk/pull/17599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17599&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324786
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17599.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17599/head:pull/17599

PR: https://git.openjdk.org/jdk/pull/17599

From darcy at openjdk.org  Fri Jan 26 22:05:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 22:05:10 GMT
Subject: Integrated: 8324786: validate-source fails after JDK-8042981
In-Reply-To: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>
References: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>
Message-ID: <en7bpYXBxm8vHf32VkJUj2dpO6oOa4QBCmIs2SsJYWg=.4132bde4-450e-40f6-9117-5a5867688a12@github.com>

On Fri, 26 Jan 2024 21:51:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for validate-source.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17599#pullrequestreview-1846604299

From dcubed at openjdk.org  Fri Jan 26 22:05:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 26 Jan 2024 22:05:10 GMT
Subject: Integrated: 8324786: validate-source fails after JDK-8042981
In-Reply-To: <en7bpYXBxm8vHf32VkJUj2dpO6oOa4QBCmIs2SsJYWg=.4132bde4-450e-40f6-9117-5a5867688a12@github.com>
References: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>
 <en7bpYXBxm8vHf32VkJUj2dpO6oOa4QBCmIs2SsJYWg=.4132bde4-450e-40f6-9117-5a5867688a12@github.com>
Message-ID: <3pVAtDnWi54fMJizmeaNcRvlSKISKDJZTG-mH_7kX9s=.e9ec79bd-9ac5-4aaa-a1fd-f3ef9708c593@github.com>

On Fri, 26 Jan 2024 21:52:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix for validate-source.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the lightning fast review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17599#issuecomment-1912744650

From darcy at openjdk.org  Fri Jan 26 22:05:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Jan 2024 22:05:10 GMT
Subject: Integrated: 8324786: validate-source fails after JDK-8042981
In-Reply-To: <en7bpYXBxm8vHf32VkJUj2dpO6oOa4QBCmIs2SsJYWg=.4132bde4-450e-40f6-9117-5a5867688a12@github.com>
References: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>
 <en7bpYXBxm8vHf32VkJUj2dpO6oOa4QBCmIs2SsJYWg=.4132bde4-450e-40f6-9117-5a5867688a12@github.com>
Message-ID: <L34EPnCjP20filjyAWQAete30wPnR5czRnzYUcrDq8Y=.d266936a-7ef2-4f63-bbc3-ef8ab621c636@github.com>

On Fri, 26 Jan 2024 21:52:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix for validate-source.
>
> Marked as reviewed by darcy (Reviewer).

> @jddarcy - Thanks for the lightning fast review!
> 
> /integrate auto

Sorry for missing that before pushing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17599#issuecomment-1912746596

From dcubed at openjdk.org  Fri Jan 26 22:05:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 26 Jan 2024 22:05:10 GMT
Subject: Integrated: 8324786: validate-source fails after JDK-8042981
In-Reply-To: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>
References: <szj77br-sK1RiufVfE6MTgLpgFkfXxAE4rl1GinYRqM=.ce01a4d8-b582-4199-abcd-e7bf2006e297@github.com>
Message-ID: <K6nCeff-CWojfUDIZYv1crxJeYsgYCRsXmeX8NFmMCA=.ef4857e7-7c48-4da7-8a61-acacafd0ba65@github.com>

On Fri, 26 Jan 2024 21:51:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for validate-source.

This pull request has now been integrated.

Changeset: 70f4a4e1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70f4a4e18e257110f45565ba0d708f1fa48aed76
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8324786: validate-source fails after JDK-8042981

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/17599

From alanb at openjdk.org  Sat Jan 27 02:15:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Jan 2024 02:15:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <UljMASUOYPJsDz_kxVJ6lnfnGsH3PS-p6jaV66nYYm0=.770a0e3a-a471-4779-9928-5365d955c529@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-not-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

"is allowed or disallowed" but the detail presents them in the reverse order. I think it would be easier to read if the allowed case went first, this goes for all the methods. I understand that disallow is the default but I think a bit easier to present in that order.

src/java.base/share/classes/javax/security/auth/Subject.java line 298:

> 296:      * {@code AccessControlContext}. When a security manager is
> 297:      * <a href=#sm-not-allowed>not allowed</a>, this method is not supported
> 298:      * and throws an {@code UnsupportedOperationException}.

I think it might be better to say "This method is intended to be used with a security manager. It throws UOE if a security manager is not allowed".

src/java.base/share/classes/javax/security/auth/Subject.java line 379:

> 377:      * current subject binds to the period of the execution of the current
> 378:      * thread. Otherwise, it is associated with the current
> 379:      * {@code AccessControlContext}.

What would you think of "If a security manager is allowed, this method is equivalent to calling getSubject with the current ACC. If a security manager is not allowed, this returns the Subject bound to the current Thread."

src/java.base/share/classes/javax/security/auth/Subject.java line 411:

> 409:      * Finally, this method invokes {@code AccessController.doPrivileged},
> 410:      * passing it the provided {@code PrivilegedAction},
> 411:      * as well as the newly constructed {@code AccessControlContext}.

I think this method would be easier to present if the allowed and not-allowed cases were in separate paragraphs. The reason is that the SM allowed case has a lot more test. For the not allowed case then it would be clearer to say that the calls the value returning function with the current Thread bound to the given Subject.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467824941
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467826752
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467829318
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467831325

From weijun at openjdk.org  Sat Jan 27 02:15:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 27 Jan 2024 02:15:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
Message-ID: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>

This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.

One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.

Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

-------------

Commit messages:
 - remove exe bits
 - remove x bit
 - the patch

Changes: https://git.openjdk.org/jdk/pull/17472/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296244
  Stats: 620 lines in 14 files changed: 464 ins; 52 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472

From duke at openjdk.org  Sat Jan 27 04:10:48 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 04:10:48 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to simplify
 object equality checks
Message-ID: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>

Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

-------------

Commit messages:
 - Fixing whitespace
 - Correcting JavaDoc
 - Fixing a bug in the provided code example.
 - Adding better documentation for more corner cases
 - Adding helpful documentation to cover corner cases
 - paren
 - Using the @snippet feature
 - Merge branch 'openjdk:master' into patch-1
 - Add new method equalsBy to java.util.Objects

Changes: https://git.openjdk.org/jdk/pull/17603/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324718
  Stats: 102 lines in 1 file changed: 101 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17603/head:pull/17603

PR: https://git.openjdk.org/jdk/pull/17603

From duke at openjdk.org  Sat Jan 27 04:21:02 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 04:21:02 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v2]
In-Reply-To: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
Message-ID: <tvVBkIc0brFaBzl7gJ39Nyq06LmGtebs3f8cJJA1f48=.77588456-e9f0-4275-8fde-00ed574592c8@github.com>

> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

David Alayachew has updated the pull request incrementally with one additional commit since the last revision:

  Aligning the documentation across examples
  
  I didn't really want to use a record since that might distract from the example for those unfamiliar with a record. But, it makes things simpler, and I want to keep my examples consistent, especially if the examples use the same name.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17603/files
  - new: https://git.openjdk.org/jdk/pull/17603/files/db5c7b43..e328c4eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17603/head:pull/17603

PR: https://git.openjdk.org/jdk/pull/17603

From duke at openjdk.org  Sat Jan 27 05:14:49 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Sat, 27 Jan 2024 05:14:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
 <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
Message-ID: <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>

On Fri, 26 Jan 2024 12:27:02 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Luckily, you and your customers are not obliged to use the JPMS

They are obliged to deal with it, and so am I as a tool maintainer. Just look the the approaches mentioned here. They all are in the category which in German we would call "von hinten durch die Brust ins Auge". That literally translates as "(a shot) from behind through the chest into the eye". Think Kennedy and "magic bullet". It means that something is unnecessarily complicated. But it is not of any developer's own choosing, but because the Java API and runtime environment requires them to jump through hoops. That is exactly what I meant before. Bytecode transformation should not be rocket science, but it progressively is developing in that direction. I have seen what Byte Buddy does to get access to an Unsafe instance, thought about what @JornVernee just suggested and have yet to look into the ByteMan source code. This all sounds pretty much like black magic and a maintenance nightmare to me.

A language ought to provide means to be productive and maybe offer some (opt-in) guard railing, but not be a corset so tight that I cannot breathe anymore. I need something that supports me without strangling me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1912999685

From duke at openjdk.org  Sat Jan 27 06:32:34 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 06:32:34 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v2]
In-Reply-To: <tvVBkIc0brFaBzl7gJ39Nyq06LmGtebs3f8cJJA1f48=.77588456-e9f0-4275-8fde-00ed574592c8@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <tvVBkIc0brFaBzl7gJ39Nyq06LmGtebs3f8cJJA1f48=.77588456-e9f0-4275-8fde-00ed574592c8@github.com>
Message-ID: <ba8KHK0qv_rUdIGVn_PP3HzUzZ6eIqniSue0gwX9J1w=.5f9094cb-2384-4ba6-b98b-4291c93d5ea7@github.com>

On Sat, 27 Jan 2024 04:21:02 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aligning the documentation across examples
>   
>   I didn't really want to use a record since that might distract from the example for those unfamiliar with a record. But, it makes things simpler, and I want to keep my examples consistent, especially if the examples use the same name.

@AlanBateman ty vm for helping!

I took a look at the CSR FAQ, and found this.

> Q: How do I create a CSR ?
> A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain.
Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.

I don't see this on my bug page. Am I looking in the wrong place? Or do I lack the permissions? -- https://bugs.openjdk.org/browse/JDK-8324718

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913031496

From duke at openjdk.org  Sat Jan 27 06:38:33 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 06:38:33 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v2]
In-Reply-To: <tvVBkIc0brFaBzl7gJ39Nyq06LmGtebs3f8cJJA1f48=.77588456-e9f0-4275-8fde-00ed574592c8@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <tvVBkIc0brFaBzl7gJ39Nyq06LmGtebs3f8cJJA1f48=.77588456-e9f0-4275-8fde-00ed574592c8@github.com>
Message-ID: <TvunmjKRA3otoadmU1SmrlbEPM4acErVYyNzfXU1nLk=.0720e898-c1a7-4995-b7e2-70d53ec60d70@github.com>

On Sat, 27 Jan 2024 04:21:02 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aligning the documentation across examples
>   
>   I didn't really want to use a record since that might distract from the example for those unfamiliar with a record. But, it makes things simpler, and I want to keep my examples consistent, especially if the examples use the same name.

Adding a screenshot to demonstrate what I see.
![image](https://github.com/openjdk/jdk/assets/38477640/3a78283a-ddce-4c34-b326-fa1203f8fde3)

Clicking NEW on the top left says that I don't have permissions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913033434

From duke at openjdk.org  Sat Jan 27 07:26:38 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 07:26:38 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v3]
In-Reply-To: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
Message-ID: <3caBSF8yCVdmbX0h2jMRYA2e28N6F9CiYgW6wP9zSl8=.64c19fbc-0c99-4342-a075-da8f53ec1af9@github.com>

> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

David Alayachew has updated the pull request incrementally with one additional commit since the last revision:

  Implied is ok, but explicit is better

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17603/files
  - new: https://git.openjdk.org/jdk/pull/17603/files/e328c4eb..dc375429

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17603/head:pull/17603

PR: https://git.openjdk.org/jdk/pull/17603

From duke at openjdk.org  Sat Jan 27 07:38:36 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 07:38:36 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v4]
In-Reply-To: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
Message-ID: <6Dms1COqaDMKZQAnN0jEmO-U4U9q3_z7sqH-dMVDAfw=.10433d07-2727-4e5a-92b2-fae2621ca2ed@github.com>

> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

David Alayachew has updated the pull request incrementally with one additional commit since the last revision:

  Correcting JavaDoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17603/files
  - new: https://git.openjdk.org/jdk/pull/17603/files/dc375429..57cb7093

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17603/head:pull/17603

PR: https://git.openjdk.org/jdk/pull/17603

From duke at openjdk.org  Sat Jan 27 07:49:48 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 07:49:48 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v5]
In-Reply-To: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
Message-ID: <k7VMvvUuFuxGKKX1-Lx2Ef-SlXXJbBbWp9QCpCnSFNE=.0fd6c70b-b453-4521-bd93-d853998e8a6c@github.com>

> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

David Alayachew has updated the pull request incrementally with one additional commit since the last revision:

  I'm sure developers would appreciate a more explicit error message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17603/files
  - new: https://git.openjdk.org/jdk/pull/17603/files/57cb7093..6d424c7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17603/head:pull/17603

PR: https://git.openjdk.org/jdk/pull/17603

From duke at openjdk.org  Sat Jan 27 07:52:56 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 07:52:56 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
Message-ID: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>

> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

David Alayachew has updated the pull request incrementally with one additional commit since the last revision:

  Rather than reiterating the precondition, let's explain why the method failed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17603/files
  - new: https://git.openjdk.org/jdk/pull/17603/files/6d424c7a..5a578015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17603&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17603/head:pull/17603

PR: https://git.openjdk.org/jdk/pull/17603

From duke at openjdk.org  Sat Jan 27 09:12:34 2024
From: duke at openjdk.org (Ismael Juma)
Date: Sat, 27 Jan 2024 09:12:34 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v3]
In-Reply-To: <MCJHjZaXcxTIozJR7q_U6bBEZmfOIw_sn-UEiarIrow=.86c09b91-e743-43e7-9066-da6b4bef7eb4@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <MCJHjZaXcxTIozJR7q_U6bBEZmfOIw_sn-UEiarIrow=.86c09b91-e743-43e7-9066-da6b4bef7eb4@github.com>
Message-ID: <JeSprOdbLqnv8I1yJnKdeCIQhIBoMu8t7hH8zzNhLIQ=.8d7807d9-a6b7-4c18-b98c-2268c6f62ae0@github.com>

On Thu, 25 Jan 2024 00:29:40 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       8768892.941            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000  LINKED_HASH_MAP  100000  avgt               ? 0          counts
>> 
>> 
>> Af...
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use max of both sizes and other maps size in case of overflow

src/java.base/share/classes/java/util/HashMap.java line 503:

> 501:      */
> 502:     final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
> 503:         int s = Math.max(size() + m.size(), m.size());

If we decide this approach is best, shouldn't we do the same for ConcurrentHashMap?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17544#discussion_r1468425767

From kevinw at openjdk.org  Sat Jan 27 11:57:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 27 Jan 2024 11:57:35 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v3]
In-Reply-To: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
Message-ID: <8G5I-7bp7jVg891XRUkSWJ6DMOoOBkhfkpNPNt40Ti0=.9e8391a5-9034-4b49-b0ee-ae3a62f37c32@github.com>

On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix nullptr only contained in strings.

test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 426:

> 424:   }
> 425: 
> 426:   // #5: Test JVMTI GetLocalObject function with nullptr value_ptr

"with null value_ptr" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17593#discussion_r1468449036

From kevinw at openjdk.org  Sat Jan 27 12:24:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 27 Jan 2024 12:24:34 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v3]
In-Reply-To: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
Message-ID: <HbaFbm_j1Qh3csmV63pbfrjGLTFpcWYTbrXCzwToHbI=.491cfdc1-0f92-4c99-a4bb-ff244f97bfb1@github.com>

On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix nullptr only contained in strings.

That is long.  Hypnotic to read. One very trivial nit, use or ignore as required, but all good that I can see.

-------------

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847074612

From liach at openjdk.org  Sat Jan 27 15:39:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Jan 2024 15:39:35 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <EdUxWhFXqMqnmy14wrXeksJcUty9bcvrD5Zzmfq0IRs=.c6189921-5d4e-4bcf-a4dc-590f8620212a@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

I fail to see the point of this new API. Existing `ObjectMethods::bootstrap` already achieves the same functionality in a better way (though the user code looks a bit more conplex), as its produced MethodHandle can be stored in a static final field and constant-fold by the JIT, while this method's argument array can't as Java arrays are not constants, and this method is polymorphic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913188740

From duke at openjdk.org  Sat Jan 27 15:52:25 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 15:52:25 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <EdUxWhFXqMqnmy14wrXeksJcUty9bcvrD5Zzmfq0IRs=.c6189921-5d4e-4bcf-a4dc-590f8620212a@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
 <EdUxWhFXqMqnmy14wrXeksJcUty9bcvrD5Zzmfq0IRs=.c6189921-5d4e-4bcf-a4dc-590f8620212a@github.com>
Message-ID: <JSuf9_FXlMb2FeDA1Sp9fHnkf8wUUaqjf2TJxepHaUQ=.83756eda-1d16-44b9-b6c7-1d80554538d5@github.com>

On Sat, 27 Jan 2024 15:36:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rather than reiterating the precondition, let's explain why the method failed
>
> I fail to see the point of this new API. Existing `ObjectMethods::bootstrap` already achieves the same functionality in a better way (though the user code looks a bit more conplex), as its produced MethodHandle can be stored in a static final field and constant-fold by the JIT, while this method's argument array can't as Java arrays are not constants, and this method is polymorphic.

Hello @liach,

Thank you for your response!

> I fail to see the point of this new API. Existing `ObjectMethods::bootstrap` already achieves the same functionality in a better way (though the user code looks a bit more conplex), as its produced MethodHandle can be stored in a static final field and constant-fold by the JIT, while this method's argument array can't as Java arrays are not constants, and this method is polymorphic.

`ObjectMethods::bootstrap` is a better fit for records, but I don't see how it could apply to general classes. Maybe you are saying a new method should instead be made on `ObjectMethods` that does something similar to the `bootstrap` method, but for classes?

Regardless, the goal of this API was to provide functionality very similar to `java.util.Comparator`, where you can provide an ad-hoc set of functions to define your comparison logic. This method is the same thing, but for equality instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913196411

From liach at openjdk.org  Sat Jan 27 16:15:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Jan 2024 16:15:27 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <eETRd7WwOp7eheDfmfwkTJao2xaLInrtOLf2dxu2Dv4=.8fc406bc-1ac0-460d-b5ad-54e59b46c0ad@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

It can be used for general classes. See an example:

public class Stuff {
  public int a, b;
  private static final MethodHandle EQUALS;

  static {
    var lookup = MethodHandles.lookup();
    try {
      EQUALS = ObjectMethods.bootstrap(lookup, "equals", MethodHandle.class, "",
          lookup.findGetter(Stuff.class, "a", int.class),
          lookup.findGetter(Stuff.class, "b", int.class));
    } catch (ReflectiveOperationException ex) {
      throw new ExceptionInInitializerError(ex);
    }
  }

  public boolean equals(Object o) {
    return EQUALS.invokeExact(this, o);
  }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913227054

From duke at openjdk.org  Sat Jan 27 16:43:34 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 16:43:34 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <eyLtv7GTxBbAc0bVIoNZNEeTYEwYQJdypIE01xlvdSU=.2a5d91f4-a158-495c-8f94-320b48b7d063@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

> It can be used for general classes. See an example:
> 
> ```java
> public class Stuff {
>   public int a, b;
>   private static final MethodHandle EQUALS;
> 
>   static {
>     var lookup = MethodHandles.lookup();
>     try {
>       EQUALS = ObjectMethods.bootstrap(lookup, "equals", MethodHandle.class, "",
>           lookup.findGetter(Stuff.class, "a", int.class),
>           lookup.findGetter(Stuff.class, "b", int.class));
>     } catch (ReflectiveOperationException ex) {
>       throw new ExceptionInInitializerError(ex);
>     }
>   }
> 
>   public boolean equals(Object o) {
>     return EQUALS.invokeExact(this, o);
>   }
> }
> ```

@liach, Ok, I concede that point.

Regardless, my original intention was to have something that could be used ad-hoc, along the lines of `Comparator`. In your example, it would be quite difficult to provide the necessary parameters ad hoc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913252584

From duke at openjdk.org  Sat Jan 27 16:54:34 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 16:54:34 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <JEyDLnlhYQ06a1mBR6fWPzq58b0dePoGRl2RFwKDMw0=.1153fa16-6f08-4905-8b10-0640ec380351@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

I also want to know, would your example not be classified as "brittle" for ad-hoc equality checks? If I refactor `Stuff` to change the field names or fields types, doesn't that mean that the example you have provided would NOT get a compilation error, but would fail at run time?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913255483

From liach at openjdk.org  Sat Jan 27 17:08:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Jan 2024 17:08:34 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <QpTSsKjKPFuhxWuSp_TsO8Z5Rn9n1VvPl1nfWPF_Txs=.58ef417c-1059-49da-9f4d-231f3db22a3a@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

Your API is risky as well: it won't get a compile error if you add a new field but forgot to add that field to equality checks too. And since initialization happens in `<clinit>`, your said error is quite easy to detect if this class is ever loaded.

If you want this example to be "not brittle" you can resort to annotation processors (essentially compiler plugins) that automatically generate invokedynamic (which is better than this explicit field approach, as this field is initialized eagerly while indy is lazy)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913261457

From liach at openjdk.org  Sat Jan 27 17:12:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Jan 2024 17:12:35 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <8O40N6Eg3M4eyu0Du0WGSvnP5S6AZ2CcwaUgC-OyyRE=.54a8d91a-e57d-4fdd-96f7-be9f0fe60812@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

If you want a simpler, straightforward approach in case your getters change as often as the objects you compare, you can do:

getters.stream().allMatch(g -> Objects.equals(g.apply(a), g.apply(b)));

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913262623

From duke at openjdk.org  Sat Jan 27 17:27:33 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 17:27:33 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <QpTSsKjKPFuhxWuSp_TsO8Z5Rn9n1VvPl1nfWPF_Txs=.58ef417c-1059-49da-9f4d-231f3db22a3a@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
 <QpTSsKjKPFuhxWuSp_TsO8Z5Rn9n1VvPl1nfWPF_Txs=.58ef417c-1059-49da-9f4d-231f3db22a3a@github.com>
Message-ID: <CpjS0gOgJhUbpir3_qbrBkJ2awsIb7OI6ZhJZ1JgHoo=.0312d57b-3606-4e34-8ae7-4c2df260cddb@github.com>

On Sat, 27 Jan 2024 17:05:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> Your API is risky as well: it won't get a compile error if you add a new field but forgot to add that field to equality checks too. And since initialization happens in `<clinit>`, your said error is quite easy to detect if this class is ever loaded.
> 
> If you want this example to be "not brittle" you can resort to annotation processors (essentially compiler plugins) that automatically generate invokedynamic (which is better than this explicit field approach, as this field is initialized eagerly while indy is lazy)

As far as I can tell, the risk of my API is fully subsetted by yours.

And while I can appreciate the suggestion to use annotations, I really question the wisdom of using an annotation for something that can be done with a simple library method. I understand that my version may not have the constant folding benefits of yours, but I am taking code that developers were already going to write and refactoring it to be slightly less error-prone and slightly more streamlined. Then, I package it into this `Objects` class and make it easy for them to understand and use. Not to mention, it's an import they probably have in hand already.

And either way, the annotation would be somewhat unclear on where/how to use it. Remember, this method isn't just to implement `equals` for a class -- it is meant to be used anywhere that we need ad-hoc equality checks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913266509

From duke at openjdk.org  Sat Jan 27 17:30:35 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 17:30:35 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <B_8uwBY3jcoWPpqOnM9Q-wiStQqU1ToL7s7doel-FzE=.ac66d81b-9e33-49bf-8e33-ac3a49104f38@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

> If you want a simpler, straightforward approach in case your getters change as often as the objects you compare, you can do:
> 
> ```java
> getters.stream().allMatch(g -> Objects.equals(g.apply(a), g.apply(b)));
> ```

Oh, I did not see this when I clicked post.

So, this solution is great if I want all the fields. But again, ad-hoc. I don't always want all the fields. I want the user to be able to choose, at use-site, which methods to use to perform equality checking on.

Furthermore, not every method will be present in the class. What if I want to compare 2 objects for the length of their `String` field? I don't want to compare if the 2 are equal, but if the lengths of them are equal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913267350

From liach at openjdk.org  Sat Jan 27 17:35:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Jan 2024 17:35:29 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <EBnqNcLKtHpUw2KzUUc184Nm8wPpbjhbnhfc4kF_al8=.f0e5565a-6fb2-4163-8284-302d9cba390a@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

I strongly disrecommend adding a library method that will become a performance burden. This method is not helpful as it is hard to optimize; I would recommend creating an alternative with this signature:

public static <T> BiPredicate<T, T> equalsBy(List<Function<T, ?>> getters)


If this getters list is constant (like from `List.of`), JIT can actually constant-fold the resulting predicate, making it much faster than your API once inlined.

Your current notation doesn't offer any opportunity for JIT compiler to treat the getters as a constant to perform optimizations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913268703

From duke at openjdk.org  Sat Jan 27 17:35:29 2024
From: duke at openjdk.org (David Alayachew)
Date: Sat, 27 Jan 2024 17:35:29 GMT
Subject: RFR: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks [v6]
In-Reply-To: <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
 <ZHl9rHkYER_CnAd19IzqssUW6JQYVmB7gYJ_P_BR1Bg=.dc23a7cf-2776-4c99-8748-2c058bb3230b@github.com>
Message-ID: <fohKi98XwBd-_Fv2u0ymkX0cnyXRu_cFGbOgIxKUNgw=.82f8ce4f-8454-4d38-8b88-e3ed6fcc1b25@github.com>

On Sat, 27 Jan 2024 07:52:56 GMT, David Alayachew <duke at openjdk.org> wrote:

>> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rather than reiterating the precondition, let's explain why the method failed

> I strongly disrecommend adding a library method that will become a performance burden. This method is not helpful as it is hard to optimize; I would recommend creating an alternative with this signature:
> 
> ```java
> public static <T> BiPredicate<T, T> equalsBy(List<Function<T, ?>> getters)
> ```
> 
> If this getters list is constant (like from `List.of`), JIT can actually constant-fold the resulting predicate, making it much faster than your API once inlined.
> 
> Your current notation doesn't offer any opportunity for JIT compiler to treat the getters as a constant to perform optimizations.

Deal. Let me make the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913269365

From coleenp at openjdk.org  Sat Jan 27 18:24:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 27 Jan 2024 18:24:45 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v4]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix one nullptr in comments as found by @kevinw

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/33786c7d..6eb051ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

PR: https://git.openjdk.org/jdk/pull/17593

From duke at openjdk.org  Sat Jan 27 22:00:26 2024
From: duke at openjdk.org (Joshua Cao)
Date: Sat, 27 Jan 2024 22:00:26 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v3]
In-Reply-To: <JeSprOdbLqnv8I1yJnKdeCIQhIBoMu8t7hH8zzNhLIQ=.8d7807d9-a6b7-4c18-b98c-2268c6f62ae0@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <MCJHjZaXcxTIozJR7q_U6bBEZmfOIw_sn-UEiarIrow=.86c09b91-e743-43e7-9066-da6b4bef7eb4@github.com>
 <JeSprOdbLqnv8I1yJnKdeCIQhIBoMu8t7hH8zzNhLIQ=.8d7807d9-a6b7-4c18-b98c-2268c6f62ae0@github.com>
Message-ID: <2vXbnfpS3bC4hOF68TmibX_HGN5N517KUMjcdD6Tam8=.82f9b370-4928-45a8-850c-e6e55ec26c02@github.com>

On Sat, 27 Jan 2024 09:09:26 GMT, Ismael Juma <duke at openjdk.org> wrote:

>> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use max of both sizes and other maps size in case of overflow
>
> src/java.base/share/classes/java/util/HashMap.java line 503:
> 
>> 501:      */
>> 502:     final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
>> 503:         int s = Math.max(size() + m.size(), m.size());
> 
> If we decide this approach is best, shouldn't we do the same for ConcurrentHashMap?

Sure. Created https://bugs.openjdk.org/browse/JDK-8324798. Won't implement that until this gets merged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17544#discussion_r1468663381

From duke at openjdk.org  Sun Jan 28 01:00:40 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 28 Jan 2024 01:00:40 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v5]
In-Reply-To: <C6pniZ1O0VryRgkxd8VgHf1uy-R89B5GndGR-gBB3Rg=.ae95b271-2a6f-4462-aff7-6a21b8ad0612@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <C6pniZ1O0VryRgkxd8VgHf1uy-R89B5GndGR-gBB3Rg=.ae95b271-2a6f-4462-aff7-6a21b8ad0612@github.com>
Message-ID: <5jrXFMYPg2eIJUCzZ12yct_g0cwS_1EqXfN8zfer44k=.b8e94df5-6876-4bb0-843e-f0812d5cdb9e@github.com>

On Fri, 12 Jan 2024 14:35:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a clarification that an `Arena` always returns zeroed-out segments for `Arena::allocate` methods.
>> 
>> Note that other overloaded methods refer to the abstract `Arena::allocate` method via implementation notes.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Add test for zero-out

test/jdk/java/foreign/TestScope.java line 150:

> 148:     }
> 149: 
> 150:     private static final MemorySegment ZEROED_MEMORY = MemorySegment.ofArray(new byte[8102]);

The?nearest power?of?two is?8192?(2<sup>13</sup>):
Suggestion:

    private static final MemorySegment ZEROED_MEMORY = MemorySegment.ofArray(new byte[8192]);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1468703138

From davidalayachew at gmail.com  Sun Jan 28 06:54:35 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 28 Jan 2024 01:54:35 -0500
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <MW4PR10MB5774D2C27CF509EE48B8DC66FF692@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <MW4PR10MB5774AA5CEDA7B1FEFDA4D07BFF692@MW4PR10MB5774.namprd10.prod.outlook.com>
 <509230836.99178022.1704910615048.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D2C27CF509EE48B8DC66FF692@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PXqXxGB0vhUxhvFAsWeW5X6gifUx1zoq0vS-PoKQv-ag@mail.gmail.com>

Thank you both for your replies!

And thanks for the Gatherer example Viktor.

It sounds like, from your email, that you want to see just how useful this
method would be to add before we can justify adding it to Gatherers.

Fair enough. I have spent a couple of days using this custom Gatherer you
made for me, and I will post a new email thread either tomorrow or the day
after that shows my experience with it. My hope is that I can convince you
that this function absolutely is worth adding.

Thank you for your time and help!
David Alayachew

On Wed, Jan 10, 2024 at 2:29?PM Viktor Klang <viktor.klang at oracle.com>
wrote:

> >1/ Is there a reason why the integrator is not declared greedy (I'm still
> not sure to what exactly Greedy means in the context of gatherers) ?
>
> No, that was just a (benign) omission from typing the solution as I was
> typing the email ?
>
> >2/ Is there a reason to write the code in a OOP way like you have done
> instead of only having fields in State and specify the behaviors using
> lambdas (because with lambdas will you get inference)
>
> Great question!
> I chose to do that since I wanted to A) allocate the backing list
> on-demand, and also B) not allocate a new ArrayList for the downstream
> windows and retain the (cleared) old one (since its size could become
> needlessly large).
>
>
> As a side-note, I tend to prototype using lambdas and then refactor
> as/when needed to either embed logic in the state or even migrate into a
> full-on implementation of the Gatherer interface (for instance if I want to
> override composition).
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
>
> ------------------------------
> *From:* Remi Forax <forax at univ-mlv.fr>
> *Sent:* Wednesday, 10 January 2024 19:16
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* David Alayachew <davidalayachew at gmail.com>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Gatherers -- conditionalWindowFixed?
>
>
>
> ------------------------------
>
> *From: *"Viktor Klang" <viktor.klang at oracle.com>
> *To: *"David Alayachew" <davidalayachew at gmail.com>, "core-libs-dev" <
> core-libs-dev at openjdk.org>
> *Sent: *Wednesday, January 10, 2024 2:33:45 PM
> *Subject: *Re: Gatherers -- conditionalWindowFixed?
>
> Hi David!
>
> Apologies for the late reply, there's been lots of catching up to do after
> the holidays.
>
> >I'm really excited for what this will enable for us.
>
> I'm really glad to hear that \uD83D\uDE42
>
> >It is very much appreciated.
>
> \uD83D\uDC4D
>
> > Could we add one more method for a conditionalWindowFixed? We would need
> to pass in some Predicate<T>. If the predicate returns true, create a list
> (if it does not already exist) then add the element to it. If the predicate
> returns false while the list is empty, then just move along to the next.
> Else if the predicate returns false while the list is non empty, pass the
> list down into the stream. So, you end up with Stream<T> ----->
> Stream<List<T>>.
>
> What ends up under Gatherers.* does require careful triaging, ideally by
> first seeing user-created implementations being heavily used/useful, then
> potential candidate for Gatherers.*, and then at the end it might end up in
> Stream as a dedicated method.
>
> By virtue of the Gatherers API, it seems pretty straight-forward for you
> to implement what you describe, and personally I'd probably call it
> something like *windowBy*.
>
> Just typing this up as I write this reply, it could look something like
> this:
>
> <TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR>
> includeInCurrentWindow) {
>   class State {
>     ArrayList<TR> window;
>
>     boolean integrate(TR element, Gatherer.Downstream<? super List<TR>>
> downstream) {
>       if (window != null && !includeInCurrentWindow.test(element)) {
>         var result = Collections.unmodifiableList(window);
>         window = null;
>         if (!downstream.push(result))
>           return false;
>       }
>
>       if (window == null)
>         window = new ArrayList<>();
>
>       return window.add(element);
>     }
>
>     void finish(Gatherer.Downstream<? super List<TR>> downstream) {
>       if (window != null) {
>         var result = Collections.unmodifiableList(window);
>         window = null;
>         downstream.push(result);
>       }
>     }
>   }
>   return Gatherer.<TR, State, List<TR>>ofSequential(State::new,
> State::integrate, State::finish);
> }
>
> jshell> Stream.of("header", "value1", "value2", "header", "header", "value
> 3", "value 4",
> null).gather(windowBy(Predicate.not("header"::equals))).toList()
> $1 ==> [[header, value1, value2], [header], [header, value 3, value 4,
> null]]
>
>
> Hello,
> I've two questions,
> 1/ Is there a reason why the integrator is not declared greedy (I'm still
> not sure to what exactly Greedy means in the context of gatherers) ?
> 2/ Is there a reason to write the code in a OOP way like you have done
> instead of only having fields in State and specify the behaviors using
> lambdas (because with lambdas will you get inference)
>
> <T> Gatherer<T, ?, List<T>> windowBy(Predicate<? super T>
> includeInCurrentWindow) {
>   class State {
>     ArrayList<T> window;
>   }
>   return Gatherer.ofSequential(
>       State::new,
>       (state, element, downstream) -> {
>        ...
>       },
>       (state, downstream) -> {
>         ...
>       });
> }
>
>
> Cheers,
> ?
>
>
> regards,
> R?mi
>
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Wednesday, 10 January 2024 07:05
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Gatherers -- conditionalWindowFixed?
>
> Hello Core Libs Dev Team,
>
> I have been reading through JEP 461 (https://openjdk.org/jeps/461) about
> Gatherers, and I'm really excited for what this will enable for us.
>
> By far, the most important functionality that this API facilitates is the
> ability to create windows. Anytime I needed a window, I was basically
> forced to use a for loop. Now, the 2 most common window cases are being
> handed to us for free. It is very much appreciated.
>
> Could we add one more method for a conditionalWindowFixed? We would need
> to pass in some Predicate<T>. If the predicate returns true, create a list
> (if it does not already exist) then add the element to it. If the predicate
> returns false while the list is empty, then just move along to the next.
> Else if the predicate returns false while the list is non empty, pass the
> list down into the stream. So, you end up with Stream<T> ----->
> Stream<List<T>>.
>
> The reason I think this is worth adding is because it facilitates a really
> common use case. We may not want all windows to be the same size.
>
> Is this something worth adding to the Gatherers API?
>
> Thank you for your time and help!
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240128/176660e3/attachment-0001.htm>

From kbarrett at openjdk.org  Sun Jan 28 20:28:26 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 Jan 2024 20:28:26 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v4]
In-Reply-To: <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
Message-ID: <Q9h9trY8ckjV5nDfdjk8hJbRTsPqYc5FVj3LrwMeZzQ=.63db64a7-f965-4190-8026-5bf73a1ac85f@github.com>

On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one nullptr in comments as found by @kevinw

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847625136

From rafael.wth at gmail.com  Sun Jan 28 22:24:05 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 28 Jan 2024 23:24:05 +0100
Subject: API for defining auxiliary classes within Java agents
Message-ID: <CA+DM0Amck3NfRCni2U0dTbuhtGPdNuSd3L+rb-g2wOW61DwGhQ@mail.gmail.com>

I wanted to revive the discussion of JDK-8200559 (
https://bugs.openjdk.org/browse/JDK-8200559) which was continued on this
GitHub ticket (https://github.com/openjdk/jdk/pull/3546).

As outlined before, Java agents are typically about more than code
instrumentation but need to define additional classes. There are two
reasons for this:

1. Agents sometimes need to define helper classes. For example, if an
instrumented method returns an interface that is a callback. If the
instrumentation wants to replace this callback, a new class needs to be
defined first.
2. Agents often need to define infrastructure for communicating with the
agent from instrumented code. For example to communicate back metrics,
tracing data or anything else that the agent is supposed to be adding.
Often, this is done by injecting a class into a class loader that can be
reached from instrumented code, which carries a static field that can carry
the "agent state" in the form of a callback object.

Previously, there has been a proposal for adding an overload with an
optional argument to ClassFileTransformer that allows to inject classes
into the package and class loader of the currently instrumented class. This
works mostly well for (1) but not so well for (2). I have however thought
about (2) some more since and wanted to suggest an alternative solution
that would make the original suggestion to solve this issue work.

The idea would be to also add a method to LambdaMetafactory. The method
would allow registering a custom metafactory dispatcher, which can carry an
agent's state and then be utilized to communicate back to the agent. This
would render the infrastructure question (2) obsolete. As a more concrete
example, this would code out the additional code:

public class LambdaMetafactory {

    private static final ConcurrentMap<String, ExternalMetafactory>
DISPATCHERS = new ConcurrentHashMap<>();

    public static void register(String id, ExternalMetafactory metafactory)
{
        Objects.requireNonNull(id, "id");
        Objects.requireNonNull(metafactory, "metafactory");
        ExternalMetafactory previous = DISPATCHERS.putIfAbsent(id,
metafactory);
        if (previous == null) {
            throw new IllegalArgumentException("External metafactory
already registered with id: " + id);
        }
    }

    public static boolean remove(String id, ExternalMetafactory
metafactory) {
      return DISPATCHERS.remove(id, metafatory);
    }

    public static CallSite externalMetafactory(MethodHandles.Lookup caller,
                                               String interfaceMethodName,
                                               MethodType factoryType,
                                               String id,
                                               Object... args) throws
LambdaConversionException {
        ExternalMetafactory dispatcher = DISPATCHERS.get(id);
        if (dispatcher == null) {
            throw new LambdaConversionException("No external metafactory
registered with id: " + id);
        }
        return dispatcher.externalConstant(caller, interfaceMethodName,
factoryType, args);
    }

    @FunctionalInterface
    public interface ExternalMetafactory {

        CallSite externalConstant(MethodHandles.Lookup caller,
                                  String interfaceMethodName,
                                  MethodType factoryType,
                                  Object... args) throws
LambdaConversionException;
    }
}

Before instrumenting any class, the agent would register a dispatcher, for
example by using a UUID as a key. Then a ClassFileTransformer would apply
instrumentations where the key is added to the class file within the
invokedynamic call site. The instrumented class can then find "its"
metafactory and install a call site that, for example, is bound to an
instance that carries the agent's state.

To some extent this metafactory would also avoid (1). The invokedynamic
bootstrap can now create a new class loader that is a child of the
instrumented class's class loader which contains the auxiliary classes
directly. Often, the created class loader would also search for classes on
the agent's class loader, which results in a very natural programming
experience as instrumentations can access both the agent's state and the
instrumented class's (or framework's) types.

I am already offering convenience for this in most of Byte Buddy's API, and
it is increasingly better adopted. I also find the resulting agents to be
much simpler to maintain and test. For an open source example, I can point
to the ElasticSearch APM agent: https://github.com/elastic/apm-agent-java

The reason this should be in the JDK is that a custom metafactory class
needs to be injected into the boot loader, the only globally visible
loader, and java.base, as the bootstrap callsite needs to be universally
visible. Using the unnamed module and opening all modules to that module
does not feel like a good solution. And there is a long row of strange
class loaders around that only check for java and javax classes when it
comes to delegating down to the boot loader. So in practice it has shown
that a custom package on the boot loader works poorly, unfortunately.

The only limitation of that approach is creating auxiliary classes that
subclass or implement package-private classes or interfaces. But this would
be covered by the original solution that was suggested to solve (1), as the
subclass does not make sense outside of the package anyways.

Summarizing: with a facility like the one above in the java.base module and
a solution as originally suggested by Mandy, I do not see a scenario that
cannot be covered and I think agents could supply everything they do today
also without using Unsafe API.

This would allow for instrumenting all class files compiled to Java 7 or
higher, which is most class files minus some JDBC drivers.Often, these
class files can be upgraded dynamically. For older JDKs, the call site
could be emulated by injecting a class using Unsafe. But for the JDK that
introduced both APIs, using an internal API would no longer be needed.

What do you think about the suggestion?
Thanks, Rafael

abc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240128/ba51f0a5/attachment.htm>

From duke at openjdk.org  Sun Jan 28 22:26:40 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sun, 28 Jan 2024 22:26:40 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@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>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
Message-ID: <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>

On Fri, 26 Jan 2024 17:19:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run the benchmarking of new DQPS in your environment with AVX?
>> 
>> Take all classes below and put them in the package org.openjdk.bench.java.util.
>> ArraysSort class contains all tests for the new versions and ready to use.
>> (it will run all tests in one execution).
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
>> 
>> Many thanks,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the JMH data below.
> 
> Thanks,
> Vamsi
> 
> Benchmark              (builder)   (size)  Mode  Cnt       Score      Error  Units
> ArraysSort.Int.a15        RANDOM      600  avgt    4       7.096 ?    0.081  us/op
> ArraysSort.Int.a15        RANDOM     2000  avgt    4      44.014 ?    1.717  us/op
> ArraysSort.Int.a15        RANDOM    90000  avgt    4    4451.444 ?   71.168  us/op
> ArraysSort.Int.a15        RANDOM   400000  avgt    4   22751.966 ?  683.597  us/op
> ArraysSort.Int.a15        RANDOM  3000000  avgt    4  190326.306 ? 8008.512  us/op
> ArraysSort.Int.a15      REPEATED      600  avgt    4       1.044 ?    0.016  us/op
> ArraysSort.Int.a15      REPEATED     2000  avgt    4       2.272 ?    0.287  us/op
> ArraysSort.Int.a15      REPEATED    90000  avgt    4     412.331 ?   11.656  us/op
> ArraysSort.Int.a15      REPEATED   400000  avgt    4    1908.978 ?   30.241  us/op
> ArraysSort.Int.a15      REPEATED  3000000  avgt    4   15163.443 ?  100.425  us/op
> ArraysSort.Int.a15       STAGGER      600  avgt    4       1.055 ?    0.057  us/op
> ArraysSort.Int.a15       STAGGER     2000  avgt    4       3.408 ?    0.096  us/op
> ArraysSort.Int.a15       STAGGER    90000  avgt    4     149.220 ?    4.022  us/op
> ArraysSort.Int.a15       STAGGER   400000  avgt    4     663.096 ?   30.252  us/op
> ArraysSort.Int.a15       STAGGER  3000000  avgt    4    5206.890 ?  234.857  us/op
> ArraysSort.Int.a15       SHUFFLE      600  avgt    4       4.611 ?    0.118  us/op
> ArraysSort.Int.a15       SHUFFLE     2000  avgt    4      17.955 ?    0.356  us/op
> ArraysSort.Int.a15       SHUFFLE    90000  avgt    4    1410.357 ?   41.128  us/op
> ArraysSort.Int.a15       SHUFFLE   400000  avgt    4    5739.311 ?  128.270  us/op
> ArraysSort.Int.a15       SHUFFLE  3000000  avgt    4   41501.980 ?  829.443  us/op
> ArraysSort.Int.jdk        RANDOM      600  avgt    4       1.612 ?    0.088  us/op
> ArraysSort.Int.jdk        RANDOM     2000  avgt    4       6.893 ?    0.375  us/op
> ArraysSort.Int.jdk        RANDOM    90000  avgt    4     522.749 ?   19.386  us/op
> ArraysSort.Int.jdk        RANDOM   400000  avgt    4    2424.204 ?   63.844  us/op
> ArraysSort.Int.jdk        RANDOM  3000000  avgt    4   21000.434 ?  801.315  us/op
> ArraysSort.Int.jdk      REPEATED      600  avgt    4       0.496 ?    0.030  us/op
> ArraysSort.Int.jdk      REPEATED     2000  avgt    4       1.037 ?    0.083  us/op
> ArraysSort.Int.jdk      REPEATED    90000  avgt    4      57.763 ?    1.955  us/op
> ArraysSort.Int.jd...

Hi Vamsi (@vamsi-parasa), Laurent(@bourgesl),

The latest benchmarking compares compares the following versions:
jdk - direct call of Arrays.sort();
a15 - the current source of DualPivotQuicksort from the latest build (except renaming)
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/DualPivotQuicksort.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java
r20s - new version without Radix sort
r20p - new version with Radix sort in parallel case only

It is expected that timing of jdk and a15 should be more or less the same, but please look at the results:

Benchmark | Data Type | Array Size | Arrays.sort() from jdk | Current source (a15)
-- | -- | -- | -- | --
ArraysSort.Int.testSort | RANDOM ? | ? ? 600 | 1.612 ? ? | 7.096
ArraysSort.Int.testSort | RANDOM ? | ? ?2000 | 6.893 ? ? | 44.014
ArraysSort.Int.testSort | RANDOM ? | ? 90000 | 522.749 ? | 4451.444
ArraysSort.Int.testSort | RANDOM ? | ?400000 | 2424.204 ?| 22751.966
ArraysSort.Int.testSort | RANDOM ? | 3000000 | 21000.434 | 190326.306
ArraysSort.Int.testSort | REPEATED | ? ? 600 | 0.496 ? ? | 1.044
ArraysSort.Int.testSort | REPEATED | ? ?2000 | 1.037 ? ? | 2.272
ArraysSort.Int.testSort | REPEATED | ? 90000 | 57.763 ? ?| 412.331
ArraysSort.Int.testSort | REPEATED | ?400000 | 182.238 ? | 1908.978
ArraysSort.Int.testSort | REPEATED | 3000000 | 1708.082 ?| 15163.443
ArraysSort.Int.testSort | STAGGER ?| ? ? 600 | 1.038 ? ? | 1.055
ArraysSort.Int.testSort | STAGGER ?| ? ?2000 | 3.434 ? ? | 3.408
ArraysSort.Int.testSort | STAGGER ?| ? 90000 | 148.638 ? | 149.220
ArraysSort.Int.testSort | STAGGER ?| ?400000 | 663.076 ? | 663.096
ArraysSort.Int.testSort | STAGGER ?| 3000000 | 5212.821 ?| 5206.890
ArraysSort.Int.testSort | SHUFFLE ?| ? ? 600 | 1.926 ? ? | 4.611
ArraysSort.Int.testSort | SHUFFLE ?| ? ?2000 | 6.858 ? ? | 17.955
ArraysSort.Int.testSort | SHUFFLE ?| ? 90000 | 473.441 ? | 1410.357
ArraysSort.Int.testSort | SHUFFLE ?| ?400000 | 2153.779 ?| 5739.311
ArraysSort.Int.testSort | SHUFFLE ?| 3000000 | 18180.141 | 41501.980

You can see that a15 (current source) works extremly slower than Arrays.sort(), but the code is the same
with minor differences: renaming and repackaging (I put the class to the test package org.openjdk.bench.java.util).
How does other package org.openjdk.bench.java.util effect so much?

I use this pom.xml file https://github.com/iaroslavski/sorting/blob/master/radixsort/pom.xml and run as following script:

`mvn clean package`
`java --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -jar target/benchmarks.jar org.openjdk.bench.java.util.ArraysSort`

It looks like intrinsics have not been applied. Check STAGGER inputs: you can see the same results because
STAGGER switches to merging sort wich doesn't contain intrinsics, but other inputs have different behaviour.

Therefore, I compare a15 (current sources) and the new version (r20p).
we can see the new version faster (only one anomaly on REPEATED, 2000).

Benchmark | Data Type | Array Size | Current source (a15) | New version (r20p) | Speedup
-- | -- | -- | -- | -- | --
ArraysSort.Int.testSort | RANDOM ? | ? ? 600 | 7.096 ? ? ?| 4.343 ? ? ?| 1.63
ArraysSort.Int.testSort | RANDOM ? | ? ?2000 | 44.014 ? ? | 20.323 ? ? | 2.17
ArraysSort.Int.testSort | RANDOM ? | ? 90000 | 4451.444 ? | 4073.793 ? | 1.09
ArraysSort.Int.testSort | RANDOM ? | ?400000 | 22751.966 ?| 19768.316 ?| 1.15
ArraysSort.Int.testSort | RANDOM ? | 3000000 | 190326.306 | 165296.770 | 1.15
ArraysSort.Int.testSort | REPEATED | ? ? 600 | 1.044 ? ? ?| 1.048 ? ? ?| 1.00
ArraysSort.Int.testSort | REPEATED | ? ?2000 | 2.272 ? ? ?| 3.212 ? ? ?| 0.71
ArraysSort.Int.testSort | REPEATED | ? 90000 | 412.331 ? ?| 410.775 ? ?| 1.00
ArraysSort.Int.testSort | REPEATED | ?400000 | 1908.978 ? | 1869.529 ? | 1.02
ArraysSort.Int.testSort | REPEATED | 3000000 | 15163.443 ?| 14302.261 ?| 1.06
ArraysSort.Int.testSort | STAGGER ?| ? ? 600 | 1.055 ? ? ?| 0.808 ? ? ?| 1.31
ArraysSort.Int.testSort | STAGGER ?| ? ?2000 | 3.408 ? ? ?| 2.683 ? ? ?| 1.27
ArraysSort.Int.testSort | STAGGER ?| ? 90000 | 149.220 ? ?| 121.519 ? ?| 1.23
ArraysSort.Int.testSort | STAGGER ?| ?400000 | 663.096 ? ?| 548.277 ? ?| 1.21
ArraysSort.Int.testSort | STAGGER ?| 3000000 | 5206.890 ? | 4496.204 ? | 1.16
ArraysSort.Int.testSort | SHUFFLE ?| ? ? 600 | 4.611 ? ? ?| 3.383 ? ? ?| 1.36
ArraysSort.Int.testSort | SHUFFLE ?| ? ?2000 | 17.955 ? ? | 11.400 ? ? | 1.57
ArraysSort.Int.testSort | SHUFFLE ?| ? 90000 | 1410.357 ? | 1001.561 ? | 1.41
ArraysSort.Int.testSort | SHUFFLE ?| ?400000 | 5739.311 ? | 4667.466 ? | 1.23
ArraysSort.Int.testSort | SHUFFLE ?| 3000000 | 41501.980 ?| 36284.178 ?| 1.14

**Parallel sort**

Benchmark | Data Type | Array Size | Current source (a15) | New version (r20p) | Speedup
-- | -- | -- | -- | -- | --
ArraysSort.Int.testParallelSort | RANDOM ? | ? ? 600 | 7.102 ? ? | 4.315 ? ?| 1.65
ArraysSort.Int.testParallelSort | RANDOM ? | ? ?2000 | 43.708 ? ?| 20.322 ? | 2.15
ArraysSort.Int.testParallelSort | RANDOM ? | ? 90000 | 743.725 ? | 409.892 ?| 1.81
ArraysSort.Int.testParallelSort | RANDOM ? | ?400000 | 3099.628 ?| 1322.129 | 2.34
ArraysSort.Int.testParallelSort | RANDOM ? | 3000000 | 25830.847 | 9790.138 | 2.64
ArraysSort.Int.testParallelSort | REPEATED | ? ? 600 | 1.042 ? ? | 1.033 ? ?| 1.01
ArraysSort.Int.testParallelSort | REPEATED | ? ?2000 | 2.273 ? ? | 3.247 ? ?| 0.70
ArraysSort.Int.testParallelSort | REPEATED | ? 90000 | 204.887 ? | 184.565 ?| 1.11
ArraysSort.Int.testParallelSort | REPEATED | ?400000 | 758.837 ? | 745.817 ?| 1.02
ArraysSort.Int.testParallelSort | REPEATED | 3000000 | 7635.330 ?| 5881.615 | 1.30
ArraysSort.Int.testParallelSort | STAGGER ?| ? ? 600 | 1.045 ? ? | 0.807 ? ?| 1.29
ArraysSort.Int.testParallelSort | STAGGER ?| ? ?2000 | 3.410 ? ? | 2.733 ? ?| 1.25
ArraysSort.Int.testParallelSort | STAGGER ?| ? 90000 | 88.093 ? ?| 73.869 ? | 1.19
ArraysSort.Int.testParallelSort | STAGGER ?| ?400000 | 218.848 ? | 208.361 ?| 1.05
ArraysSort.Int.testParallelSort | STAGGER ?| 3000000 | 2245.299 ?| 2122.314 | 1.06
ArraysSort.Int.testParallelSort | SHUFFLE ?| ? ? 600 | 4.594 ? ? | 3.386 ? ?| 1.36
ArraysSort.Int.testParallelSort | SHUFFLE ?| ? ?2000 | 17.759 ? ?| 11.570 ? | 1.53
ArraysSort.Int.testParallelSort | SHUFFLE ?| ? 90000 | 293.962 ? | 146.273 ?| 2.01
ArraysSort.Int.testParallelSort | SHUFFLE ?| ?400000 | 1017.350 ?| 766.287 ?| 1.33
ArraysSort.Int.testParallelSort | SHUFFLE ?| 3000000 | 7419.434 ?| 5917.997 | 1.25

Vamsi (@vamsi-parasa),
Could you please check your pom.xml and script to be sure that we use the same environment?
Are intrinsics not applied in package org.openjdk.bench.java.util?
Can you rerun benchmarking when classes a15, r20s and r20p are under package java.util?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1913741195

From winterhalter at openjdk.org  Sun Jan 28 22:31:49 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Sun, 28 Jan 2024 22:31:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <7rswMpX1cL2AfryP_cxE3X7Hk842-nUFBQaWYMnKUcU=.782c5798-190b-449b-a2cb-db230dc8bab4@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

I tried to give the discussion a fresh start but moved it to the mailing list: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118622.html

I have given this some thought the recent years, so I hope that there is a solution in reach that satisfies everybody's concerns and needs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1913742617

From winterhalter at openjdk.org  Sun Jan 28 22:35:48 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Sun, 28 Jan 2024 22:35:48 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
 <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
Message-ID: <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>

On Thu, 25 Jan 2024 10:04:08 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> pass a non-null Instrumentation instance i.e. to have agent capabilities.

What stops people from supplying a fake instance? Wouldn't you need to "test run" the instance first?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1913743577

From acobbs at openjdk.org  Sun Jan 28 23:26:51 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 28 Jan 2024 23:26:51 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v6]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <CWhcoN44dkAPUgbaLuwCnwka0AXgZEfE63F_WdON5FU=.c0dc7d6d-6107-4b43-9a0d-0f489aea78d2@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Reword the @implSpec note for clarity per PR discussion.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/7f96511e..a4d82c67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=04-05

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From dholmes at openjdk.org  Mon Jan 29 05:32:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Jan 2024 05:32:34 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v4]
In-Reply-To: <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
Message-ID: <mbjNOPXWZ93rQLnQzXpRHq1-dyU3vK6fj9L_INFgTdI=.ce754a0a-ebf5-485d-97df-a2bed6d76e1e@github.com>

On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one nullptr in comments as found by @kevinw

Looks good. Thanks for doing the text changes as well, they are a necessary part of the cleanup.

A number of files are missing copyright updates - the ones I spotted all had a single copyright year so maybe your script missed them?

My browser found 21 places where nullptr is cast to something else, which should no longer be needed.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847855251

From vlivanov at openjdk.org  Mon Jan 29 06:40:28 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 29 Jan 2024 06:40:28 GMT
Subject: RFR: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler [v7]
In-Reply-To: <LLt2-zCWyMXBn30mOdLNdkyiAevoPy49VrmOGg9lB9Q=.cc37047e-63da-4764-b0d3-a734668262ba@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
 <LLt2-zCWyMXBn30mOdLNdkyiAevoPy49VrmOGg9lB9Q=.cc37047e-63da-4764-b0d3-a734668262ba@github.com>
Message-ID: <FOyarMqpL1FTVlTUKz_diL71rHEcUYSiOSQ0VBFSGd0=.78688e02-dcdf-43f0-81bc-3f346af18240@github.com>

On Thu, 25 Jan 2024 14:01:59 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
>> 
>> Please kindly give your opinion as well as your reviews, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change expr to val, add examples

I share Roland's concerns w.r.t. profiling. If there's any code guarded by `isCompileConstant(value) == true`, the only way to trigger its profiling is by deoptimizing from C2-generated code.

I added `MHI.isCompileConstant` intrinsic as part of a point fix for a performance problem caused by Java-level code profiling/specialization happening in `java.lang.invoke`. It guards profiling logic which is pruned completely once C2 kicks in. So, absence of profiling is not a problem there. 

Also, there's a constraint on implementation side: the current implementation supports only parse-time folding. If a value turns into a constant later (either during parsing after the call is encountered or during post-parsing phase), it won't have any effect.

So, as it is now (both on API and implementation sides) it's hard to correctly use `isCompileConstant` for more general cases.

It would be helpful to see more examples illustrating possible usage scenarios.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1914052884

From viktor.klang at oracle.com  Mon Jan 29 07:41:21 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 29 Jan 2024 07:41:21 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <1735570874.107417931.1705768809128.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774EFF5686D69377BB68F34FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB57741879B012B7B9957D83C4FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>

For monomorphic benches it is likely not going to make any difference as the JIT will likely do the same thing, also, the bench might be dominated by other factors.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 25 January 2024 14:57
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Wednesday, January 24, 2024 2:45:15 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
As a (related) side-note, the ability to implement the interface directly has a significant benefit to being able to have tighter control on efficiency/performance as well as behavior under composition, here are some examples: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java*L113__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3h3t54rw$>

I've not seen any differences in term of performance:

MapGathererBenchmark.gatherer_map_sum                avgt    5  546.058 ? 4.224  us/op
MapGathererBenchmark.gatherer_mapsublcass_sum  avgt    5  546.391 ? 1.508  us/op

but yes, being able to override andThen() is important.


Cheers,
?


R?mi


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang <viktor.klang at oracle.com>
Sent: Wednesday, 24 January 2024 14:34
To: forax at univ-mlv.fr <forax at univ-mlv.fr>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: Re: Gatherer: spliterator characteristics are not propagated

Presuming that you mean mutating the Gatherer such that its behavior isn't stable, the difference (at least to me) is that creating such a mutable Gatherer would violate the specification of Gatherer: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java*L63__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3uXOerfv$>



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Tuesday, 23 January 2024 21:04
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 10:06:27 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.
But I presume this also requires to have a `int characteristics()`-method on the Gatherer interfacewhich means that users who are not using the factory methods will have full possibility of not only returning the flags, but returning any int.

The current implementation suffers the same kind of issue, it's easy to write a mutable Gatherer and change the functions after creation, worst, right in the middle of a call to stream.gather(...).

Perhaps the Gatherer interface should be sealed ? We did not have that option during the 1.8 timeframe, when the Collector API was created.



The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.
I can see where you're coming from here, but to me, adding API surface needs to pull its weight.
In this case I wasn't convinced that it did, hence we're having this conversation. \uD83D\uDE42

Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated


________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.





Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.


public static int toOpFlags(int characteristics) {
return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---

public class GathererFlag {
// cut and paste from StreamOpFlag
  /**
   * The bit pattern for setting/injecting a flag.
   */
private static final int SET_BITS = 0b01;

/**
   * The bit pattern for clearing a flag.
   */
private static final int CLEAR_BITS = 0b10;

/**
   * The bit pattern for preserving a flag.
   */
private static final int PRESERVE_BITS = 0b11;


private static int position(int opFlagSet) {
return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
  }

private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
private static final int STATELESS_POSITION = 14;
private static final int PARELLIZABLE_POSITION = 15;

public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

// no GREEDY here
private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

private static final int STREAM_OP_MASK =
      ((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

public static String toString(int characteristics) {
return Stream.of(characteristics)
        .<String>mapMulti((f, consumer) -> {
if ((f & PARELLIZABLE) == PARELLIZABLE) {
consumer.accept("PARELLIZABLE");
          }
if ((f & STATELESS) == STATELESS) {
consumer.accept("STATELESS");
          }
if ((f & GREEDY) == GREEDY) {
consumer.accept("GREEDY");
          }
if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
consumer.accept("KEEP_DISTINCT");
          }
if ((f & KEEP_SORTED) == KEEP_SORTED) {
consumer.accept("KEEP_SORTED");
          }
if ((f & KEEP_SIZED) == KEEP_SIZED) {
consumer.accept("KEEP_SIZED");
          }
        })
        .collect(Collectors.joining(", "));
  }

public static int toOpFlags(int characteristics) {
return  ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240129/ac1e01db/attachment-0001.htm>

From forax at univ-mlv.fr  Mon Jan 29 09:42:37 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 29 Jan 2024 10:42:37 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB57741879B012B7B9957D83C4FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB57741879B012B7B9957D83C4FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1736791414.115021330.1706521357568.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Monday, January 29, 2024 8:41:21 AM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> For monomorphic benches it is likely not going to make any difference as the JIT
> will likely do the same thing, also, the bench might be dominated by other
> factors.

For me, it's more that lambdas may be able to use late-inlining (inlining after the return value of an invokedynamic is known as constant) so results may be better than it should. 
Here is an example, 

@Benchmark 
public boolean map_allMatch_repeat_3 () { 
return integers .stream() 
.map( v -> v + 1 ) 
.map( v -> v + 2 ) 
.map( v -> v + 3 ) 
.allMatch( v -> v < 1_000_000 ); 
} 
@Benchmark 
public boolean mapToInt_allMatch_repeat_3 () { 
return integers .stream() 
.mapToInt( v -> v + 1 ) 
.map( v -> v + 2 ) 
.map( v -> v + 3 ) 
.allMatch( v -> v < 1_000_000 ); 
} 
@Benchmark 
public boolean gatherer_map_allMatch_repeat_3 () { 
// Gatherer with lambdas 
return integers .stream() 
.gather( map ( v -> v + 1 )) 
.gather( map ( v -> v + 2 )) 
.gather( map ( v -> v + 3 )) 
.allMatch( v -> v < 1_000_000 ); 
} 
@Benchmark 
public boolean gatherer_mapsublcass_allMatch_repeat_3 () { 
// Gatherer as subclass 
return integers .stream() 
.gather( mapSubclass ( v -> v + 1 )) 
.gather( mapSubclass ( v -> v + 2 )) 
.gather( mapSubclass ( v -> v + 3 )) 
.allMatch( v -> v < 1_000_000 ); 
} 

With 10 second warmups, 
Benchmark                                                    Mode  Cnt     Score     Error  Units 
MapGathererBenchmark.gatherer_map_allMatch_repeat_3          avgt    5  3359.336 ? 137.314  us/op 
MapGathererBenchmark.gatherer_mapsublcass_allMatch_repeat_3  avgt    5  3755.388 ?  50.858  us/op 
MapGathererBenchmark.mapToInt_allMatch_repeat_3              avgt    5   559.891 ?   1.542  us/op 
MapGathererBenchmark.map_allMatch_repeat_3                   avgt    5  1642.167 ?   5.804  us/op 

Also, I wonder if fusing is not an anti-pattern for gatherers/streams, c2 take a loooong time to come with as code wich is not very fast. 

> Cheers,
> ?

R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Thursday, 25 January 2024 14:57
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Wednesday, January 24, 2024 2:45:15 PM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> As a (related) side-note, the ability to implement the interface directly has a
>> significant benefit to being able to have tighter control on
>> efficiency/performance as well as behavior under composition, here are some
>> examples: [
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java*L113__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3h3t54rw$
>> |
>> https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113
>> ]

> I've not seen any differences in term of performance:
> MapGathererBenchmark.gatherer_map_sum?????????       avgt??? 5? 546.058 ? 4.224
> ? us/op
> MapGathererBenchmark.gatherer_mapsublcass_sum? avgt??? 5? 546.391 ? 1.508? us/op
> but yes, being able to override andThen() is important.

>> Cheers,
>> ?

> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang
>> <viktor.klang at oracle.com>
>> Sent: Wednesday, 24 January 2024 14:34
>> To: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: Re: Gatherer: spliterator characteristics are not propagated
>> Presuming that you mean mutating the Gatherer such that its behavior isn't
>> stable, the difference (at least to me) is that creating such a mutable
>> Gatherer would violate the specification of Gatherer: [
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java*L63__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3uXOerfv$
>> |
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63
>> ]

>> Cheers,
>> ?

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Tuesday, 23 January 2024 21:04
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Monday, January 22, 2024 10:06:27 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>> The flags are in sync with the implementation because the only way to create a
>>>> Gatherer if through the factory methods and those factory methods (and only
>>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>>> user.

>>> But I presume this also requires to have a `int characteristics()`-method on the
>>> Gatherer interfacewhich means that users who are not using the factory methods
>>> will have full possibility of not only returning the flags, but returning any
>>> int.

>> The current implementation suffers the same kind of issue, it's easy to write a
>> mutable Gatherer and change the functions after creation, worst, right in the
>> middle of a call to stream.gather(...).

>> Perhaps the Gatherer interface should be sealed ? We did not have that option
>> during the 1.8 timeframe, when the Collector API was created.

>>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>>> good citizen and works seemlessly with the other intermediary operations.

>>> I can see where you're coming from here, but to me, adding API surface needs to
>>> pull its weight.
>>> In this case I wasn't convinced that it did, hence we're having this
>>> conversation. \uD83D\uDE42

>>> Cheers,
>>> ?

>> regards,
>> R?mi

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Monday, 22 January 2024 19:56
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>> <psandoz at openjdk.java.net>
>>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>> Hi R?mi,

>>> Hello,

>>>> For instance, stateless is neither recessive nor dominant, since the composition
>>>> of two stateless operations is only ever stateless if they both are greedy as
>>>> well: [
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>>> |
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>>> ]

>>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>>> the combination is ad-hoc, reflecting the characterristics is enough.

>>>> So even if making it represented as ints (more like Spliterator, rather than
>>>> Collector) makes things faster, it's still both work to track, propagate, and
>>>> also becomes a side-channel that needs to remain in sync with the actual
>>>> implementation of the logic.

>>> The flags are in sync with the implementation because the only way to create a
>>> Gatherer if through the factory methods and those factory methods (and only
>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>> user.

>>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>>> performance bug/inefficiency in an of itself as it would be faster to do
>>>> someCollection.size().

>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>> good citizen and works seemlessly with the other intermediary operations.

>>> Cheers,
>>> ?

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Monday, 22 January 2024 19:56
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>> <psandoz at openjdk.java.net>
>>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>> Hi R?mi,

>>> Hello,

>>>> For instance, stateless is neither recessive nor dominant, since the composition
>>>> of two stateless operations is only ever stateless if they both are greedy as
>>>> well: [
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>>> |
>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>>> ]

>>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>>> the combination is ad-hoc, reflecting the characterristics is enough.

>>>> So even if making it represented as ints (more like Spliterator, rather than
>>>> Collector) makes things faster, it's still both work to track, propagate, and
>>>> also becomes a side-channel that needs to remain in sync with the actual
>>>> implementation of the logic.

>>> The flags are in sync with the implementation because the only way to create a
>>> Gatherer if through the factory methods and those factory methods (and only
>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>> user.

>>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>>> performance bug/inefficiency in an of itself as it would be faster to do
>>>> someCollection.size().

>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>> good citizen and works seemlessly with the other intermediary operations.

>>>> Cheers,
>>>> ?

>>> regards,
>>> R?mi

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>> Sent: Saturday, 20 January 2024 17:40
>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>> <psandoz at openjdk.java.net>
>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>> propagated

>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>> <psandoz at openjdk.java.net>
>>>>> Sent: Thursday, January 18, 2024 5:14:38 PM
>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>>>> both gatherers keep it sorted.

>>>>> That is unfortunately not the case. That would presume that you can implement
>>>>> the composition such that it can preserve all the common flags. Some flags
>>>>> could be "dominant" and some "recessive" to use genetics nomenclature.

>>>> Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not
>>>> the characteristics of the Gatherer which can have the corresponding "dominant"
>>>> flag, GREEDY, in this case.
>>>> And the same for sequential, the flag should be PARALELIZABLE and not
>>>> SEQUENTIAL.

>>>> The idea is that the Gatherer characteristics can have the same bit set at the
>>>> same position as the stream op flags (as defined by StreamOpFlag).
>>>> So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED
>>>> is in position 3.
>>>> For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit
>>>> (using XOR) when we want to extract the stream op flags from the
>>>> characteristics

>>>> All the factory methods call the generic of() with a combination of
>>>> PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY,
>>>> KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be
>>>> raised).

>>>> In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for
>>>> our two new states PARALELIZABLE and STATELESS, so no problem here (technically
>>>> we can also reuse positions of the Spliterator characteristic given that those
>>>> flags are masked before being sent to the GathererOp super constructor).

>>>> The way to transform a Gatherer characteristics op to a stream flags op is to
>>>> flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags
>>>> but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask
>>>> to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

>>>> public static int toOpFlags ( int characteristics ) {
>>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>>> STREAM_OP_MASK ;
>>>> }

>>>> see below for a full script.

>>>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>>>> and i do not understand how it can make the other operations slower.

>>>>> Extra invocations, extra storage, and extra composition overhead is not free.
>>>>> Since Stream is one-shot you need to include the construction cost with the
>>>>> execution cost. For something like an empty Stream construction cost scan be
>>>>> 90+% of the total costs.

>>>> If you create a Gatherer, the characteristics is a constant (so the validity
>>>> check is removed, it's just a mask and a test) so the result of calling
>>>> toOpFlags() is a constant too.

>>>> If the factory method is not inlined, the cost is 3 bitwise operations which is
>>>> I believe faster than the "instanceof Greedy" used in the current code.

>>>>> Cheers,
>>>>> ?

>>>> regards,
>>>> R?mi

>>>> ---
>>>> public class GathererFlag {
>>>> // cut and paste from StreamOpFlag
>>>> /**
>>>> * The bit pattern for setting/injecting a flag.
>>>> */
>>>> private static final int SET_BITS = 0b01 ;

>>>> /**
>>>> * The bit pattern for clearing a flag.
>>>> */
>>>> private static final int CLEAR_BITS = 0b10 ;

>>>> /**
>>>> * The bit pattern for preserving a flag.
>>>> */
>>>> private static final int PRESERVE_BITS = 0b11 ;

>>>> private static int position ( int opFlagSet ) {
>>>> return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ;
>>>> }

>>>> private static final int DISTINCT_POSITION = position ( StreamOpFlag .
>>>> IS_DISTINCT );
>>>> private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED
>>>> );
>>>> private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED );

>>>> private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag .
>>>> IS_SHORT_CIRCUIT );
>>>> private static final int STATELESS_POSITION = 14 ;
>>>> private static final int PARELLIZABLE_POSITION = 15 ;

>>>> public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1
>>>> );
>>>> public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 );
>>>> public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 );

>>>> public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 );
>>>> public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 );
>>>> public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 );

>>>> private static final int SHORT_CIRCUIT_MASK = SET_BITS << (
>>>> SHORT_CIRCUIT_POSITION << 1 );

>>>> // no GREEDY here
>>>> private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS |
>>>> KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ;

>>>> private static final int STREAM_OP_MASK =
>>>> (( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) |
>>>> GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ;

>>>> public static String toString ( int characteristics ) {
>>>> return Stream . of ( characteristics )
>>>> .< String >mapMulti(( f , consumer ) -> {
>>>> if (( f & PARELLIZABLE ) == PARELLIZABLE ) {
>>>> consumer .accept( "PARELLIZABLE" );
>>>> }
>>>> if (( f & STATELESS ) == STATELESS ) {
>>>> consumer .accept( "STATELESS" );
>>>> }
>>>> if (( f & GREEDY ) == GREEDY ) {
>>>> consumer .accept( "GREEDY" );
>>>> }
>>>> if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) {
>>>> consumer .accept( "KEEP_DISTINCT" );
>>>> }
>>>> if (( f & KEEP_SORTED ) == KEEP_SORTED ) {
>>>> consumer .accept( "KEEP_SORTED" );
>>>> }
>>>> if (( f & KEEP_SIZED ) == KEEP_SIZED ) {
>>>> consumer .accept( "KEEP_SIZED" );
>>>> }
>>>> })
>>>> .collect( Collectors . joining ( ", " ));
>>>> }

>>>> public static int toOpFlags ( int characteristics ) {
>>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>>> STREAM_OP_MASK ;
>>>> }

>>>> public static String toOpFlagsString ( int opFlags ) {
>>>> return Arrays . stream ( StreamOpFlag . values ())
>>>> .map( op -> {
>>>> if ( op .isPreserved( opFlags )) {
>>>> return "preserved " + op ;
>>>> }
>>>> if ( op .isCleared( opFlags )) {
>>>> return "cleared " + op ;
>>>> }
>>>> if ( op .isKnown( opFlags )) {
>>>> return "set " + op ;
>>>> }
>>>> return "?? " + op ;
>>>> })
>>>> .collect( Collectors . joining ( ", " ));
>>>> }

>>>> void main () {
>>>> var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT |
>>>> KEEP_SORTED | KEEP_SIZED ;
>>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics )));

>>>> var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ;
>>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 )));
>>>> }
>>>> }

>>>>> Viktor Klang
>>>>> Software Architect, Java Platform Group
>>>>> Oracle

>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>> Sent: Thursday, 18 January 2024 16:17
>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>> <psandoz at openjdk.java.net>
>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>> propagated

>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>>> <psandoz at openjdk.java.net>
>>>>>> Sent: Thursday, January 18, 2024 3:36:07 PM
>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>>>>>> others will want to be able to have INJECT-flags, and then people might have
>>>>>> different opinions w.r.t. the default should be to clear all flags etc.

>>>>>> And that's even before one looks at the composition-part of it, what are the
>>>>>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>>>>>> set of flags always approaches 0)

>>>>>> I spent quite a bit of time on this and in the end tracking all this info, and
>>>>>> making sure that the flags of implementations correspond to the actual
>>>>>> behavior, just ended up costing performance for most streams and introduced an
>>>>>> extra dimension to creation and maintenance which I had a hard time justifying.

>>>>> It can be a slippery slope if we were designing from the ground up but the
>>>>> stream implementation already exists and SORTED, DISTINCT and SIZED are the
>>>>> flags that are already tracked by the current implementation.

>>>>> Currently only SHORT_CIRCUIT is set (if not greedy),
>>>>> see [
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
>>>>> |
>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
>>>>> ]

>>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>>> both gatherers keep it sorted.

>>>>>> Making specific, rare, combinations of operations faster at the expense of
>>>>>> making 99% of all others slower is a hard pill for most to swallow.

>>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>>> and i do not understand how it can make the other operations slower.

>>>>>> Cheers,
>>>>>> ?

>>>>> regards,
>>>>> R?mi

>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle

>>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>>> Sent: Thursday, 18 January 2024 10:28
>>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>>> <psandoz at openjdk.java.net>
>>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>>> propagated

>>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>>>>>> <core-libs-dev at openjdk.java.net>
>>>>>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>>> Hi R?mi,

>>>>>>> You can find some of my benches here: [
>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>>>>>> |
>>>>>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>>>>>> ]

>>>>>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>>>>>> didn't end up worth it when looking at the bench results over a wide array of
>>>>>>> stream sizes and number of operations.

>>>>>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>>>>>> KEEP_DISTINCT and KEEP_SIZED,
>>>>>> all of them say that if the stream was sorted/distinct/sized then the stream
>>>>>> returned by a call to gather() is still sorted (with the same comparator),
>>>>>> distinct or sized.

>>>>>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>>>>>> windowFixed is KEEP_DISTINCT.

>>>>>> [CC Paul, so he can correct me if i'm saying something stupid]

>>>>>> Now for the benchmarks, it depends what you want to measure, benchmarking
>>>>>> streams is tricky. This is what i know about benchmarking streams.
>>>>>> First, the JIT has two ways to profile types at runtime,
>>>>>> Either a method takes a function as parameter
>>>>>> void map(Function function) {
>>>>>> function.apply(...)
>>>>>> }
>>>>>> and when map is called with a subtype of Function, the JIT will propagate the
>>>>>> exact type when map is inlined,
>>>>>> Or a method use a field
>>>>>> class Op {
>>>>>> Function function;

>>>>>> void map() {
>>>>>> function.apply(...)
>>>>>> }
>>>>>> }
>>>>>> in that case, the VM records the profile of function.apply() and if there are
>>>>>> more than two different profiles, the VM declare profile poluttion and do not
>>>>>> try to optimize.

>>>>>> The Stream implementation tries very hard to use only parameters instead of
>>>>>> fields, that's why it does not use classical Iterator that are pull iterator (a
>>>>>> filter iterator requires a field) but a Spliterator which is a push iterator,
>>>>>> the element is sent as parameter of the consumer.That's also why collect does
>>>>>> not use the builder pattern (that accumulate values in fields) but a Collector
>>>>>> that publish the functions to be called as parameter.

>>>>>> Obvisously, this is more complex than that, a Collector stores the functions in
>>>>>> fields so it should not work well but the implementation uses a record that
>>>>>> plays well with escape analysis. Escape analysis see the fields of an instance
>>>>>> as parameters so the functions of a Collector are correctly propagated (if the
>>>>>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>>>>>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>>>>>> are routinely fully inlined with the intermediate operation of a stream.

>>>>>> In your tests, i've not seen comparaisons between an existing method like map()
>>>>>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>>>>>> where the characteristics KEEP_* have an impact and their equivalent using a
>>>>>> Gatherer.

>>>>>>> Cheers,
>>>>>>> ?

>>>>>> regards,
>>>>>> R?mi

>>>>>>> Viktor Klang
>>>>>>> Software Architect, Java Platform Group
>>>>>>> Oracle

>>>>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>>>>>> <forax at univ-mlv.fr>
>>>>>>> Sent: Wednesday, 17 January 2024 16:48
>>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>>> Subject: Gatherer: spliterator characteristics are not propagated
>>>>>>> While doing some benchmarking of the Gatherer API, i've found that the
>>>>>>> characteristics of the spliterator was not propagated by the method
>>>>>>> Stream.gather() making the stream slower than it should.

>>>>>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>>>>>> that this intermediate operation keep the size, which is important if the
>>>>>>> terminal operation is toList() because if the size is known, toList() will
>>>>>>> presize the List and avoid the creation of an intermediary ArrayList.

>>>>>>> See [
>>>>>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>>>>>> |
>>>>>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>>>>>> ]

>>>>>>> I think that adding a way to propagate the spliterator characteristics through a
>>>>>>> Gatherer would greatly improve the performance of commons streams (at least all
>>>>>>> the ones that end with a call to toList).

>>>>>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>>>>>> something and if improving the performance is something worth changing the API.

>>>>>>> regards,
>>>>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240129/ba4453fd/attachment-0001.htm>

From viktor.klang at oracle.com  Mon Jan 29 10:07:02 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 29 Jan 2024 10:07:02 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <1736791414.115021330.1706521357568.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <1109096043.109135158.1705949799994.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774884A8D1A94A89F5A2F95FF752@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB57741879B012B7B9957D83C4FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1736791414.115021330.1706521357568.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774D1BF4E6FF898F917E2E1FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>

If you have a look at my benchmarks, currently I only fuse gather(?) + collect(?) (so in this case not allMatch).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 29 January 2024 10:42
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 29, 2024 8:41:21 AM
Subject: Re: Gatherer: spliterator characteristics are not propagated
For monomorphic benches it is likely not going to make any difference as the JIT will likely do the same thing, also, the bench might be dominated by other factors.

For me, it's more that lambdas may be able to use late-inlining (inlining after the return value of an invokedynamic is known as constant) so results may be better than it should.
Here is an example,


@Benchmark
public boolean map_allMatch_repeat_3() {
  return integers.stream()
    .map(v -> v + 1)
    .map(v -> v + 2)
    .map(v -> v + 3)
    .allMatch(v -> v < 1_000_000);
}
@Benchmark
public boolean mapToInt_allMatch_repeat_3() {
  return integers.stream()
    .mapToInt(v -> v + 1)
    .map(v -> v + 2)
    .map(v -> v + 3)
    .allMatch(v -> v < 1_000_000);
}
@Benchmark
public boolean gatherer_map_allMatch_repeat_3() {
  // Gatherer with lambdas
  return integers.stream()
    .gather(map(v -> v + 1))
    .gather(map(v -> v + 2))
    .gather(map(v -> v + 3))
    .allMatch(v -> v < 1_000_000);
}
@Benchmark
public boolean gatherer_mapsublcass_allMatch_repeat_3() {
  // Gatherer as subclass
  return integers.stream()
    .gather(mapSubclass(v -> v + 1))
    .gather(mapSubclass(v -> v + 2))
    .gather(mapSubclass(v -> v + 3))
    .allMatch(v -> v < 1_000_000);
}

With 10 second warmups,

Benchmark                                                    Mode  Cnt     Score     Error  Units
MapGathererBenchmark.gatherer_map_allMatch_repeat_3          avgt    5  3359.336 ? 137.314  us/op
MapGathererBenchmark.gatherer_mapsublcass_allMatch_repeat_3  avgt    5  3755.388 ?  50.858  us/op
MapGathererBenchmark.mapToInt_allMatch_repeat_3              avgt    5   559.891 ?   1.542  us/op
MapGathererBenchmark.map_allMatch_repeat_3                   avgt    5  1642.167 ?   5.804  us/op


Also, I wonder if fusing is not an anti-pattern for gatherers/streams, c2 take a loooong time to come with as code wich is not very fast.





Cheers,
?

R?mi


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 25 January 2024 14:57
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Wednesday, January 24, 2024 2:45:15 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

As a (related) side-note, the ability to implement the interface directly has a significant benefit to being able to have tighter control on efficiency/performance as well as behavior under composition, here are some examples: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java*L113__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3h3t54rw$>


I've not seen any differences in term of performance:

MapGathererBenchmark.gatherer_map_sum                avgt    5  546.058 ? 4.224  us/op
MapGathererBenchmark.gatherer_mapsublcass_sum  avgt    5  546.391 ? 1.508  us/op

but yes, being able to override andThen() is important.


Cheers,
?



R?mi


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang <viktor.klang at oracle.com>
Sent: Wednesday, 24 January 2024 14:34
To: forax at univ-mlv.fr <forax at univ-mlv.fr>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: Re: Gatherer: spliterator characteristics are not propagated

Presuming that you mean mutating the Gatherer such that its behavior isn't stable, the difference (at least to me) is that creating such a mutable Gatherer would violate the specification of Gatherer: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java*L63__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3uXOerfv$>



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Tuesday, 23 January 2024 21:04
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 10:06:27 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.
But I presume this also requires to have a `int characteristics()`-method on the Gatherer interfacewhich means that users who are not using the factory methods will have full possibility of not only returning the flags, but returning any int.

The current implementation suffers the same kind of issue, it's easy to write a mutable Gatherer and change the functions after creation, worst, right in the middle of a call to stream.gather(...).

Perhaps the Gatherer interface should be sealed ? We did not have that option during the 1.8 timeframe, when the Collector API was created.



The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.
I can see where you're coming from here, but to me, adding API surface needs to pull its weight.
In this case I wasn't convinced that it did, hence we're having this conversation. \uD83D\uDE42

Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated


________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.





Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

public static int toOpFlags(int characteristics) {
return ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---
public class GathererFlag {
// cut and paste from StreamOpFlag
/**
* The bit pattern for setting/injecting a flag.
*/
private static final int SET_BITS = 0b01;

/**
* The bit pattern for clearing a flag.
*/
private static final int CLEAR_BITS = 0b10;

/**
* The bit pattern for preserving a flag.
*/
private static final int PRESERVE_BITS = 0b11;


private static int position(int opFlagSet) {
return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
}

private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
private static final int STATELESS_POSITION = 14;
private static final int PARELLIZABLE_POSITION = 15;

public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

// no GREEDY here
private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

private static final int STREAM_OP_MASK =
((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

public static String toString(int characteristics) {
return Stream.of(characteristics)
.<String>mapMulti((f, consumer) -> {
if ((f & PARELLIZABLE) == PARELLIZABLE) {
consumer.accept("PARELLIZABLE");
}
if ((f & STATELESS) == STATELESS) {
consumer.accept("STATELESS");
}
if ((f & GREEDY) == GREEDY) {
consumer.accept("GREEDY");
}
if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
consumer.accept("KEEP_DISTINCT");
}
if ((f & KEEP_SORTED) == KEEP_SORTED) {
consumer.accept("KEEP_SORTED");
}
if ((f & KEEP_SIZED) == KEEP_SIZED) {
consumer.accept("KEEP_SIZED");
}
})
.collect(Collectors.joining(", "));
}

public static int toOpFlags(int characteristics) {
return ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240129/9e7d6c9d/attachment-0001.htm>

From forax at univ-mlv.fr  Mon Jan 29 11:23:36 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 29 Jan 2024 12:23:36 +0100 (CET)
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <MW4PR10MB5774D1BF4E6FF898F917E2E1FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB57741879B012B7B9957D83C4FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1736791414.115021330.1706521357568.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D1BF4E6FF898F917E2E1FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1828350822.115111473.1706527416933.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <psandoz at openjdk.java.net>
> Sent: Monday, January 29, 2024 11:07:02 AM
> Subject: Re: Gatherer: spliterator characteristics are not propagated

> If you have a look at my benchmarks, currently I only fuse gather(?) +
> collect(?) (so in this case not allMatch).

You also fuse repetitive calls to gather() 
[ https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L64 | https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L64 ] 

> Cheers,
> ?

R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Monday, 29 January 2024 10:42
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
> <psandoz at openjdk.java.net>
> Subject: [External] : Re: Gatherer: spliterator characteristics are not
> propagated

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>> <psandoz at openjdk.java.net>
>> Sent: Monday, January 29, 2024 8:41:21 AM
>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>> For monomorphic benches it is likely not going to make any difference as the JIT
>> will likely do the same thing, also, the bench might be dominated by other
>> factors.

> For me, it's more that lambdas may be able to use late-inlining (inlining after
> the return value of an invokedynamic is known as constant) so results may be
> better than it should.
> Here is an example,

> @Benchmark
> public boolean map_allMatch_repeat_3 () {
> return integers .stream()
> .map( v -> v + 1 )
> .map( v -> v + 2 )
> .map( v -> v + 3 )
> .allMatch( v -> v < 1_000_000 );
> }
> @Benchmark
> public boolean mapToInt_allMatch_repeat_3 () {
> return integers .stream()
> .mapToInt( v -> v + 1 )
> .map( v -> v + 2 )
> .map( v -> v + 3 )
> .allMatch( v -> v < 1_000_000 );
> }
> @Benchmark
> public boolean gatherer_map_allMatch_repeat_3 () {
> // Gatherer with lambdas
> return integers .stream()
> .gather( map ( v -> v + 1 ))
> .gather( map ( v -> v + 2 ))
> .gather( map ( v -> v + 3 ))
> .allMatch( v -> v < 1_000_000 );
> }
> @Benchmark
> public boolean gatherer_mapsublcass_allMatch_repeat_3 () {
> // Gatherer as subclass
> return integers .stream()
> .gather( mapSubclass ( v -> v + 1 ))
> .gather( mapSubclass ( v -> v + 2 ))
> .gather( mapSubclass ( v -> v + 3 ))
> .allMatch( v -> v < 1_000_000 );
> }

> With 10 second warmups,
> Benchmark                                                    Mode  Cnt     Score
>     Error  Units
> MapGathererBenchmark.gatherer_map_allMatch_repeat_3          avgt    5  3359.336
> ? 137.314  us/op
> MapGathererBenchmark.gatherer_mapsublcass_allMatch_repeat_3  avgt    5  3755.388
> ?  50.858  us/op
> MapGathererBenchmark.mapToInt_allMatch_repeat_3              avgt    5   559.891
> ?   1.542  us/op
> MapGathererBenchmark.map_allMatch_repeat_3                   avgt    5  1642.167
> ?   5.804  us/op

> Also, I wonder if fusing is not an anti-pattern for gatherers/streams, c2 take a
> loooong time to come with as code wich is not very fast.

>> Cheers,
>> ?

> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>> Sent: Thursday, 25 January 2024 14:57
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>> <psandoz at openjdk.java.net>
>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>> propagated

>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>> <psandoz at openjdk.java.net>
>>> Sent: Wednesday, January 24, 2024 2:45:15 PM
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>> As a (related) side-note, the ability to implement the interface directly has a
>>> significant benefit to being able to have tighter control on
>>> efficiency/performance as well as behavior under composition, here are some
>>> examples: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java*L113__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3h3t54rw$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113
>>> ]

>> I've not seen any differences in term of performance:
>> MapGathererBenchmark.gatherer_map_sum?????????       avgt??? 5? 546.058 ? 4.224
>> ? us/op
>> MapGathererBenchmark.gatherer_mapsublcass_sum? avgt??? 5? 546.391 ? 1.508? us/op
>> but yes, being able to override andThen() is important.

>>> Cheers,
>>> ?

>> R?mi

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang
>>> <viktor.klang at oracle.com>
>>> Sent: Wednesday, 24 January 2024 14:34
>>> To: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: Re: Gatherer: spliterator characteristics are not propagated
>>> Presuming that you mean mutating the Gatherer such that its behavior isn't
>>> stable, the difference (at least to me) is that creating such a mutable
>>> Gatherer would violate the specification of Gatherer: [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java*L63__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3uXOerfv$
>>> |
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63
>>> ]

>>> Cheers,
>>> ?

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle

>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>> Sent: Tuesday, 23 January 2024 21:04
>>> To: Viktor Klang <viktor.klang at oracle.com>
>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>> <psandoz at openjdk.java.net>
>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>> propagated

>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>> <psandoz at openjdk.java.net>
>>>> Sent: Monday, January 22, 2024 10:06:27 PM
>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> The flags are in sync with the implementation because the only way to create a
>>>>> Gatherer if through the factory methods and those factory methods (and only
>>>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>>>> user.

>>>> But I presume this also requires to have a `int characteristics()`-method on the
>>>> Gatherer interfacewhich means that users who are not using the factory methods
>>>> will have full possibility of not only returning the flags, but returning any
>>>> int.

>>> The current implementation suffers the same kind of issue, it's easy to write a
>>> mutable Gatherer and change the functions after creation, worst, right in the
>>> middle of a call to stream.gather(...).

>>> Perhaps the Gatherer interface should be sealed ? We did not have that option
>>> during the 1.8 timeframe, when the Collector API was created.

>>>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>>>> good citizen and works seemlessly with the other intermediary operations.

>>>> I can see where you're coming from here, but to me, adding API surface needs to
>>>> pull its weight.
>>>> In this case I wasn't convinced that it did, hence we're having this
>>>> conversation. \uD83D\uDE42

>>>> Cheers,
>>>> ?

>>> regards,
>>> R?mi

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>> Sent: Monday, 22 January 2024 19:56
>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>> <psandoz at openjdk.java.net>
>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>> propagated

>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>> <psandoz at openjdk.java.net>
>>>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> Hi R?mi,

>>>> Hello,

>>>>> For instance, stateless is neither recessive nor dominant, since the composition
>>>>> of two stateless operations is only ever stateless if they both are greedy as
>>>>> well: [
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>>>> |
>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>>>> ]

>>>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>>>> the combination is ad-hoc, reflecting the characterristics is enough.

>>>>> So even if making it represented as ints (more like Spliterator, rather than
>>>>> Collector) makes things faster, it's still both work to track, propagate, and
>>>>> also becomes a side-channel that needs to remain in sync with the actual
>>>>> implementation of the logic.

>>>> The flags are in sync with the implementation because the only way to create a
>>>> Gatherer if through the factory methods and those factory methods (and only
>>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>>> user.

>>>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>>>> performance bug/inefficiency in an of itself as it would be faster to do
>>>>> someCollection.size().

>>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>>> good citizen and works seemlessly with the other intermediary operations.

>>>> Cheers,
>>>> ?

>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle

>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>> Sent: Monday, 22 January 2024 19:56
>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>> <psandoz at openjdk.java.net>
>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>> propagated

>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>> <psandoz at openjdk.java.net>
>>>>> Sent: Monday, January 22, 2024 4:22:11 PM
>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>> Hi R?mi,

>>>> Hello,

>>>>> For instance, stateless is neither recessive nor dominant, since the composition
>>>>> of two stateless operations is only ever stateless if they both are greedy as
>>>>> well: [
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$
>>>>> |
>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588
>>>>> ]

>>>> Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that
>>>> the combination is ad-hoc, reflecting the characterristics is enough.

>>>>> So even if making it represented as ints (more like Spliterator, rather than
>>>>> Collector) makes things faster, it's still both work to track, propagate, and
>>>>> also becomes a side-channel that needs to remain in sync with the actual
>>>>> implementation of the logic.

>>>> The flags are in sync with the implementation because the only way to create a
>>>> Gatherer if through the factory methods and those factory methods (and only
>>>> them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user
>>>> should not be able to set those flags. Only the flags KEEP_* are settable by a
>>>> user.

>>>>> One could argue that logic such as: someCollection.stream().map(?).count() is a
>>>>> performance bug/inefficiency in an of itself as it would be faster to do
>>>>> someCollection.size().

>>>> The stream implementation has a whole mechanism in place to propagate/preverse
>>>> flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of
>>>> this mechanism seems a little off topic. I would prefer the Gatherer to be a
>>>> good citizen and works seemlessly with the other intermediary operations.

>>>>> Cheers,
>>>>> ?

>>>> regards,
>>>> R?mi

>>>>> Viktor Klang
>>>>> Software Architect, Java Platform Group
>>>>> Oracle

>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>> Sent: Saturday, 20 January 2024 17:40
>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>> <psandoz at openjdk.java.net>
>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>> propagated

>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>>> <psandoz at openjdk.java.net>
>>>>>> Sent: Thursday, January 18, 2024 5:14:38 PM
>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>>>>> both gatherers keep it sorted.

>>>>>> That is unfortunately not the case. That would presume that you can implement
>>>>>> the composition such that it can preserve all the common flags. Some flags
>>>>>> could be "dominant" and some "recessive" to use genetics nomenclature.

>>>>> Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not
>>>>> the characteristics of the Gatherer which can have the corresponding "dominant"
>>>>> flag, GREEDY, in this case.
>>>>> And the same for sequential, the flag should be PARALELIZABLE and not
>>>>> SEQUENTIAL.

>>>>> The idea is that the Gatherer characteristics can have the same bit set at the
>>>>> same position as the stream op flags (as defined by StreamOpFlag).
>>>>> So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED
>>>>> is in position 3.
>>>>> For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit
>>>>> (using XOR) when we want to extract the stream op flags from the
>>>>> characteristics

>>>>> All the factory methods call the generic of() with a combination of
>>>>> PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY,
>>>>> KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be
>>>>> raised).

>>>>> In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for
>>>>> our two new states PARALELIZABLE and STATELESS, so no problem here (technically
>>>>> we can also reuse positions of the Spliterator characteristic given that those
>>>>> flags are masked before being sent to the GathererOp super constructor).

>>>>> The way to transform a Gatherer characteristics op to a stream flags op is to
>>>>> flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags
>>>>> but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask
>>>>> to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

>>>>> public static int toOpFlags ( int characteristics ) {
>>>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>>>> STREAM_OP_MASK ;
>>>>> }

>>>>> see below for a full script.

>>>>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>>>>> and i do not understand how it can make the other operations slower.

>>>>>> Extra invocations, extra storage, and extra composition overhead is not free.
>>>>>> Since Stream is one-shot you need to include the construction cost with the
>>>>>> execution cost. For something like an empty Stream construction cost scan be
>>>>>> 90+% of the total costs.

>>>>> If you create a Gatherer, the characteristics is a constant (so the validity
>>>>> check is removed, it's just a mask and a test) so the result of calling
>>>>> toOpFlags() is a constant too.

>>>>> If the factory method is not inlined, the cost is 3 bitwise operations which is
>>>>> I believe faster than the "instanceof Greedy" used in the current code.

>>>>>> Cheers,
>>>>>> ?

>>>>> regards,
>>>>> R?mi

>>>>> ---
>>>>> public class GathererFlag {
>>>>> // cut and paste from StreamOpFlag
>>>>> /**
>>>>> * The bit pattern for setting/injecting a flag.
>>>>> */
>>>>> private static final int SET_BITS = 0b01 ;

>>>>> /**
>>>>> * The bit pattern for clearing a flag.
>>>>> */
>>>>> private static final int CLEAR_BITS = 0b10 ;

>>>>> /**
>>>>> * The bit pattern for preserving a flag.
>>>>> */
>>>>> private static final int PRESERVE_BITS = 0b11 ;

>>>>> private static int position ( int opFlagSet ) {
>>>>> return Integer . numberOfTrailingZeros ( opFlagSet ) >> 1 ;
>>>>> }

>>>>> private static final int DISTINCT_POSITION = position ( StreamOpFlag .
>>>>> IS_DISTINCT );
>>>>> private static final int SORTED_POSITION = position ( StreamOpFlag . IS_SORTED
>>>>> );
>>>>> private static final int SIZED_POSITION = position ( StreamOpFlag . IS_SIZED );

>>>>> private static final int SHORT_CIRCUIT_POSITION = position ( StreamOpFlag .
>>>>> IS_SHORT_CIRCUIT );
>>>>> private static final int STATELESS_POSITION = 14 ;
>>>>> private static final int PARELLIZABLE_POSITION = 15 ;

>>>>> public static final int PARELLIZABLE = SET_BITS << ( PARELLIZABLE_POSITION << 1
>>>>> );
>>>>> public static final int STATELESS = SET_BITS << ( STATELESS_POSITION << 1 );
>>>>> public static final int GREEDY = SET_BITS << ( SHORT_CIRCUIT_POSITION << 1 );

>>>>> public static final int KEEP_DISTINCT = SET_BITS << ( DISTINCT_POSITION << 1 );
>>>>> public static final int KEEP_SORTED = SET_BITS << ( SORTED_POSITION << 1 );
>>>>> public static final int KEEP_SIZED = SET_BITS << ( SIZED_POSITION << 1 );

>>>>> private static final int SHORT_CIRCUIT_MASK = SET_BITS << (
>>>>> SHORT_CIRCUIT_POSITION << 1 );

>>>>> // no GREEDY here
>>>>> private static final int HIGHER_BITS = ( PARELLIZABLE | STATELESS |
>>>>> KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ;

>>>>> private static final int STREAM_OP_MASK =
>>>>> (( GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ) << 1 ) |
>>>>> GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED ;

>>>>> public static String toString ( int characteristics ) {
>>>>> return Stream . of ( characteristics )
>>>>> .< String >mapMulti(( f , consumer ) -> {
>>>>> if (( f & PARELLIZABLE ) == PARELLIZABLE ) {
>>>>> consumer .accept( "PARELLIZABLE" );
>>>>> }
>>>>> if (( f & STATELESS ) == STATELESS ) {
>>>>> consumer .accept( "STATELESS" );
>>>>> }
>>>>> if (( f & GREEDY ) == GREEDY ) {
>>>>> consumer .accept( "GREEDY" );
>>>>> }
>>>>> if (( f & KEEP_DISTINCT ) == KEEP_DISTINCT ) {
>>>>> consumer .accept( "KEEP_DISTINCT" );
>>>>> }
>>>>> if (( f & KEEP_SORTED ) == KEEP_SORTED ) {
>>>>> consumer .accept( "KEEP_SORTED" );
>>>>> }
>>>>> if (( f & KEEP_SIZED ) == KEEP_SIZED ) {
>>>>> consumer .accept( "KEEP_SIZED" );
>>>>> }
>>>>> })
>>>>> .collect( Collectors . joining ( ", " ));
>>>>> }

>>>>> public static int toOpFlags ( int characteristics ) {
>>>>> return (( characteristics ^ SHORT_CIRCUIT_MASK ) | HIGHER_BITS ) &
>>>>> STREAM_OP_MASK ;
>>>>> }

>>>>> public static String toOpFlagsString ( int opFlags ) {
>>>>> return Arrays . stream ( StreamOpFlag . values ())
>>>>> .map( op -> {
>>>>> if ( op .isPreserved( opFlags )) {
>>>>> return "preserved " + op ;
>>>>> }
>>>>> if ( op .isCleared( opFlags )) {
>>>>> return "cleared " + op ;
>>>>> }
>>>>> if ( op .isKnown( opFlags )) {
>>>>> return "set " + op ;
>>>>> }
>>>>> return "?? " + op ;
>>>>> })
>>>>> .collect( Collectors . joining ( ", " ));
>>>>> }

>>>>> void main () {
>>>>> var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT |
>>>>> KEEP_SORTED | KEEP_SIZED ;
>>>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics )));

>>>>> var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED ;
>>>>> System . out .println( toOpFlagsString ( toOpFlags ( characteristics2 )));
>>>>> }
>>>>> }

>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle

>>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>>> Sent: Thursday, 18 January 2024 16:17
>>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>>> <psandoz at openjdk.java.net>
>>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>>> propagated

>>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
>>>>>>> <psandoz at openjdk.java.net>
>>>>>>> Sent: Thursday, January 18, 2024 3:36:07 PM
>>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>>> I suspect that it is a rather slippery slope, once KEEP-flags are added, then
>>>>>>> others will want to be able to have INJECT-flags, and then people might have
>>>>>>> different opinions w.r.t. the default should be to clear all flags etc.

>>>>>>> And that's even before one looks at the composition-part of it, what are the
>>>>>>> flags for A.andThen(B)? (then extrapolate to N compositions and the available
>>>>>>> set of flags always approaches 0)

>>>>>>> I spent quite a bit of time on this and in the end tracking all this info, and
>>>>>>> making sure that the flags of implementations correspond to the actual
>>>>>>> behavior, just ended up costing performance for most streams and introduced an
>>>>>>> extra dimension to creation and maintenance which I had a hard time justifying.

>>>>>> It can be a slippery slope if we were designing from the ground up but the
>>>>>> stream implementation already exists and SORTED, DISTINCT and SIZED are the
>>>>>> flags that are already tracked by the current implementation.

>>>>>> Currently only SHORT_CIRCUIT is set (if not greedy),
>>>>>> see [
>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$
>>>>>> |
>>>>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209
>>>>>> ]

>>>>>> And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if
>>>>>> both gatherers keep it sorted.

>>>>>>> Making specific, rare, combinations of operations faster at the expense of
>>>>>>> making 99% of all others slower is a hard pill for most to swallow.

>>>>>> I suppose that if those flags already exist, it's because they have a purpose
>>>>>> and i do not understand how it can make the other operations slower.

>>>>>>> Cheers,
>>>>>>> ?

>>>>>> regards,
>>>>>> R?mi

>>>>>>> Viktor Klang
>>>>>>> Software Architect, Java Platform Group
>>>>>>> Oracle

>>>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>>>> Sent: Thursday, 18 January 2024 10:28
>>>>>>> To: Viktor Klang <viktor.klang at oracle.com>
>>>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz
>>>>>>> <psandoz at openjdk.java.net>
>>>>>>> Subject: [External] : Re: Gatherer: spliterator characteristics are not
>>>>>>> propagated

>>>>>>>> From: "Viktor Klang" <viktor.klang at oracle.com>
>>>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>>>>>>> <core-libs-dev at openjdk.java.net>
>>>>>>>> Sent: Wednesday, January 17, 2024 8:48:07 PM
>>>>>>>> Subject: Re: Gatherer: spliterator characteristics are not propagated

>>>>>>>> Hi R?mi,

>>>>>>>> You can find some of my benches here: [
>>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$
>>>>>>>> |
>>>>>>>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
>>>>>>>> ]

>>>>>>>> Initially I had Characteristics such as ORDERED etc on Gatherer but it just
>>>>>>>> didn't end up worth it when looking at the bench results over a wide array of
>>>>>>>> stream sizes and number of operations.

>>>>>>> I think there are 3 gatherer characteristics that make sense: KEEP_SORTED,
>>>>>>> KEEP_DISTINCT and KEEP_SIZED,
>>>>>>> all of them say that if the stream was sorted/distinct/sized then the stream
>>>>>>> returned by a call to gather() is still sorted (with the same comparator),
>>>>>>> distinct or sized.

>>>>>>> As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and
>>>>>>> windowFixed is KEEP_DISTINCT.

>>>>>>> [CC Paul, so he can correct me if i'm saying something stupid]

>>>>>>> Now for the benchmarks, it depends what you want to measure, benchmarking
>>>>>>> streams is tricky. This is what i know about benchmarking streams.
>>>>>>> First, the JIT has two ways to profile types at runtime,
>>>>>>> Either a method takes a function as parameter
>>>>>>> void map(Function function) {
>>>>>>> function.apply(...)
>>>>>>> }
>>>>>>> and when map is called with a subtype of Function, the JIT will propagate the
>>>>>>> exact type when map is inlined,
>>>>>>> Or a method use a field
>>>>>>> class Op {
>>>>>>> Function function;

>>>>>>> void map() {
>>>>>>> function.apply(...)
>>>>>>> }
>>>>>>> }
>>>>>>> in that case, the VM records the profile of function.apply() and if there are
>>>>>>> more than two different profiles, the VM declare profile poluttion and do not
>>>>>>> try to optimize.

>>>>>>> The Stream implementation tries very hard to use only parameters instead of
>>>>>>> fields, that's why it does not use classical Iterator that are pull iterator (a
>>>>>>> filter iterator requires a field) but a Spliterator which is a push iterator,
>>>>>>> the element is sent as parameter of the consumer.That's also why collect does
>>>>>>> not use the builder pattern (that accumulate values in fields) but a Collector
>>>>>>> that publish the functions to be called as parameter.

>>>>>>> Obvisously, this is more complex than that, a Collector stores the functions in
>>>>>>> fields so it should not work well but the implementation uses a record that
>>>>>>> plays well with escape analysis. Escape analysis see the fields of an instance
>>>>>>> as parameters so the functions of a Collector are correctly propagated (if the
>>>>>>> escape analysis works). And lambdas are using invokedynamic, and the VM tries
>>>>>>> really hard to inline invokedynamic, so lambdas (that captures value or not)
>>>>>>> are routinely fully inlined with the intermediate operation of a stream.

>>>>>>> In your tests, i've not seen comparaisons between an existing method like map()
>>>>>>> or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations
>>>>>>> where the characteristics KEEP_* have an impact and their equivalent using a
>>>>>>> Gatherer.

>>>>>>>> Cheers,
>>>>>>>> ?

>>>>>>> regards,
>>>>>>> R?mi

>>>>>>>> Viktor Klang
>>>>>>>> Software Architect, Java Platform Group
>>>>>>>> Oracle

>>>>>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>>>>>>>> <forax at univ-mlv.fr>
>>>>>>>> Sent: Wednesday, 17 January 2024 16:48
>>>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>>>> Subject: Gatherer: spliterator characteristics are not propagated
>>>>>>>> While doing some benchmarking of the Gatherer API, i've found that the
>>>>>>>> characteristics of the spliterator was not propagated by the method
>>>>>>>> Stream.gather() making the stream slower than it should.

>>>>>>>> As an example, there is no way when reimplementing map() using a Gatherer to say
>>>>>>>> that this intermediate operation keep the size, which is important if the
>>>>>>>> terminal operation is toList() because if the size is known, toList() will
>>>>>>>> presize the List and avoid the creation of an intermediary ArrayList.

>>>>>>>> See [
>>>>>>>> https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$
>>>>>>>> |
>>>>>>>> https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java
>>>>>>>> ]

>>>>>>>> I think that adding a way to propagate the spliterator characteristics through a
>>>>>>>> Gatherer would greatly improve the performance of commons streams (at least all
>>>>>>>> the ones that end with a call to toList).

>>>>>>>> I have some idea of how to do that, but I prefer first to hear if i've overlook
>>>>>>>> something and if improving the performance is something worth changing the API.

>>>>>>>> regards,
>>>>>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240129/25b0cc7e/attachment-0001.htm>

From viktor.klang at oracle.com  Mon Jan 29 11:30:59 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 29 Jan 2024 11:30:59 +0000
Subject: Gatherer: spliterator characteristics are not propagated
In-Reply-To: <1828350822.115111473.1706527416933.JavaMail.zimbra@univ-eiffel.fr>
References: <709983326.105056079.1705506526036.JavaMail.zimbra@univ-eiffel.fr>
 <1077398948.110395075.1706040268304.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774B7E20ACB82B52D3F9FC7FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57747EF92881EC23380114F0FF7B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <831042719.112207852.1706191054519.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB57741879B012B7B9957D83C4FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1736791414.115021330.1706521357568.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D1BF4E6FF898F917E2E1FF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1828350822.115111473.1706527416933.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB577415089645A781942E99FFFF7E2@MW4PR10MB5774.namprd10.prod.outlook.com>

Yes, I meant intermediate + terminal fusion, if you use allMatch then that will not be fused (at the moment) as that is a short-circuiting terminal operation (which cannot be expressed with Collector), so you'd have to use an AllMatch Gatherer + a get first element collector<https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L45> to get fusion all the way through the terminal operation.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 29 January 2024 12:23
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 29, 2024 11:07:02 AM
Subject: Re: Gatherer: spliterator characteristics are not propagated
If you have a look at my benchmarks, currently I only fuse gather(?) + collect(?) (so in this case not allMatch).

You also fuse repetitive calls to gather()
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L64<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L64__;Iw!!ACWV5N9M2RV99hQ!IGQyt8jWkgu4TjoTJa4R4ehIgUy4j8oBIpwUh1hGANSzxi8odsqrkhMHEWNzUj-VA1QboUbKnc5kcCH0Swqv$>



Cheers,
?

R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 29 January 2024 10:42
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 29, 2024 8:41:21 AM
Subject: Re: Gatherer: spliterator characteristics are not propagated
For monomorphic benches it is likely not going to make any difference as the JIT will likely do the same thing, also, the bench might be dominated by other factors.

For me, it's more that lambdas may be able to use late-inlining (inlining after the return value of an invokedynamic is known as constant) so results may be better than it should.
Here is an example,


@Benchmark
public boolean map_allMatch_repeat_3() {
  return integers.stream()
    .map(v -> v + 1)
    .map(v -> v + 2)
    .map(v -> v + 3)
    .allMatch(v -> v < 1_000_000);
}
@Benchmark
public boolean mapToInt_allMatch_repeat_3() {
  return integers.stream()
    .mapToInt(v -> v + 1)
    .map(v -> v + 2)
    .map(v -> v + 3)
    .allMatch(v -> v < 1_000_000);
}
@Benchmark
public boolean gatherer_map_allMatch_repeat_3() {
  // Gatherer with lambdas
  return integers.stream()
    .gather(map(v -> v + 1))
    .gather(map(v -> v + 2))
    .gather(map(v -> v + 3))
    .allMatch(v -> v < 1_000_000);
}
@Benchmark
public boolean gatherer_mapsublcass_allMatch_repeat_3() {
  // Gatherer as subclass
  return integers.stream()
    .gather(mapSubclass(v -> v + 1))
    .gather(mapSubclass(v -> v + 2))
    .gather(mapSubclass(v -> v + 3))
    .allMatch(v -> v < 1_000_000);
}

With 10 second warmups,

Benchmark                                                    Mode  Cnt     Score     Error  Units
MapGathererBenchmark.gatherer_map_allMatch_repeat_3          avgt    5  3359.336 ? 137.314  us/op
MapGathererBenchmark.gatherer_mapsublcass_allMatch_repeat_3  avgt    5  3755.388 ?  50.858  us/op
MapGathererBenchmark.mapToInt_allMatch_repeat_3              avgt    5   559.891 ?   1.542  us/op
MapGathererBenchmark.map_allMatch_repeat_3                   avgt    5  1642.167 ?   5.804  us/op


Also, I wonder if fusing is not an anti-pattern for gatherers/streams, c2 take a loooong time to come with as code wich is not very fast.





Cheers,
?

R?mi


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 25 January 2024 14:57
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Wednesday, January 24, 2024 2:45:15 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

As a (related) side-note, the ability to implement the interface directly has a significant benefit to being able to have tighter control on efficiency/performance as well as behavior under composition, here are some examples: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java#L113<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java*L113__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3h3t54rw$>


I've not seen any differences in term of performance:

MapGathererBenchmark.gatherer_map_sum                avgt    5  546.058 ? 4.224  us/op
MapGathererBenchmark.gatherer_mapsublcass_sum  avgt    5  546.391 ? 1.508  us/op

but yes, being able to override andThen() is important.


Cheers,
?



R?mi


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang <viktor.klang at oracle.com>
Sent: Wednesday, 24 January 2024 14:34
To: forax at univ-mlv.fr <forax at univ-mlv.fr>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: Re: Gatherer: spliterator characteristics are not propagated

Presuming that you mean mutating the Gatherer such that its behavior isn't stable, the difference (at least to me) is that creating such a mutable Gatherer would violate the specification of Gatherer: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L63<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java*L63__;Iw!!ACWV5N9M2RV99hQ!MFknMPf08p9oLTHtcHIIljRuma7ct6sarJRqTWKzmBiiGJBjtDEZsgGrkDbwxLl1NhEwVwz-RhHv3uXOerfv$>



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Tuesday, 23 January 2024 21:04
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 10:06:27 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.
But I presume this also requires to have a `int characteristics()`-method on the Gatherer interfacewhich means that users who are not using the factory methods will have full possibility of not only returning the flags, but returning any int.

The current implementation suffers the same kind of issue, it's easy to write a mutable Gatherer and change the functions after creation, worst, right in the middle of a call to stream.gather(...).

Perhaps the Gatherer interface should be sealed ? We did not have that option during the 1.8 timeframe, when the Collector API was created.



The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.
I can see where you're coming from here, but to me, adding API surface needs to pull its weight.
In this case I wasn't convinced that it did, hence we're having this conversation. \uD83D\uDE42

Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated


________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.





Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Monday, 22 January 2024 19:56
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Monday, January 22, 2024 4:22:11 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

Hello,


For instance, stateless is neither recessive nor dominant, since the composition of two stateless operations is only ever stateless if they both are greedy as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java#L588<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java*L588__;Iw!!ACWV5N9M2RV99hQ!Lm52jd6kovd5t-cmrqqSLiRcIajBGXLxh85LO3eeiL6UxbKZuNPcUnO6z2i0FzMEoNr7U-cOBuWPCjo57FVW$>

Okay, so choosing SEQUENTIAL vs PARALELLIZABLE is not that important given that the combination is ad-hoc, reflecting the characterristics is enough.


So even if making it represented as ints (more like Spliterator, rather than Collector) makes things faster, it's still both work to track, propagate, and also becomes a side-channel that needs to remain in sync with the actual implementation of the logic.

The flags are in sync with the implementation because the only way to create a Gatherer if through the factory methods and those factory methods (and only them) compute the proper combination of SEQUENTIAL | STATELESS | GREEDY. A user should not be able to set those flags. Only the flags KEEP_* are settable by a user.


One could argue that logic such as: someCollection.stream().map(?).count() is a performance bug/inefficiency in an of itself as it would be faster to do someCollection.size().

The stream implementation has a whole mechanism in place to propagate/preverse flags like SIZED, DISTINCT or SORTED. For me, discussing about the merit of this mechanism seems a little off topic.  I would prefer the Gatherer to be a good citizen and works seemlessly with the other intermediary operations.


Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Saturday, 20 January 2024 17:40
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 5:14:38 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.
That is unfortunately not the case. That would presume that you can implement the composition such that it can preserve all the common flags. Some flags could be "dominant" and some "recessive" to use genetics nomenclature.

Some flags of the stream pipeline are "recessive", mainly SHORT_CIRCUIT, but not the characteristics of the Gatherer which can have the corresponding "dominant" flag, GREEDY, in this case.
And the same for sequential, the flag should be PARALELIZABLE and not SEQUENTIAL.

The idea is that the Gatherer characteristics can have the same bit set at the same position as the stream op flags (as defined by StreamOpFlag).
So KEEP_DISTINCT is in position 0, KEEP_SORTED in in position 2 and KEEP_SIZED is in position 3.
For GREEDY, we use the same position as SHORT_CIRCUIT and we will flip the bit (using XOR) when we want to extract the stream op flags from the characteristics

All the factory methods call the generic of() with a combination of PARALELIZABLE and STATELESS and the user can adds the characteristics GREEDY, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED (otherwise an exception should be raised).

In StreamOpFlag, there are two unused positions (14 and 15), that's perfect for our two new states PARALELIZABLE and STATELESS, so no problem here (technically we can also reuse positions of the Spliterator characteristic given that those flags are masked before being sent to the GathererOp super constructor).

The way to transform a Gatherer characteristics op to a stream flags op is to flip the bits corresponding to SHORT_CIRCUIT, add the highter bit of all flags but SHORT-CIRCUIT (because stream op flags are encoded using 2 bits) and mask to only retain SHORT_CIRCUIT, KEEP_DISTINCT, KEEP_SORTED and KEEP_SIZED.

public static int toOpFlags(int characteristics) {
return ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

see below for a full script.



I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.

Extra invocations, extra storage, and extra composition overhead is not free. Since Stream is one-shot you need to include the construction cost with the execution cost. For something like an empty Stream construction cost scan be 90+% of the total costs.

If you create a Gatherer, the characteristics is a constant (so the validity check is removed, it's just a mask and a test) so the result of calling toOpFlags() is a constant too.

If the factory method is not inlined, the cost is 3 bitwise operations which is I believe faster than the "instanceof Greedy" used in the current code.


Cheers,
?

regards,
R?mi

---
public class GathererFlag {
// cut and paste from StreamOpFlag
/**
* The bit pattern for setting/injecting a flag.
*/
private static final int SET_BITS = 0b01;

/**
* The bit pattern for clearing a flag.
*/
private static final int CLEAR_BITS = 0b10;

/**
* The bit pattern for preserving a flag.
*/
private static final int PRESERVE_BITS = 0b11;


private static int position(int opFlagSet) {
return Integer.numberOfTrailingZeros(opFlagSet) >> 1;
}

private static final int DISTINCT_POSITION = position(StreamOpFlag.IS_DISTINCT);
private static final int SORTED_POSITION = position(StreamOpFlag.IS_SORTED);
private static final int SIZED_POSITION = position(StreamOpFlag.IS_SIZED);

private static final int SHORT_CIRCUIT_POSITION = position(StreamOpFlag.IS_SHORT_CIRCUIT);
private static final int STATELESS_POSITION = 14;
private static final int PARELLIZABLE_POSITION = 15;

public static final int PARELLIZABLE = SET_BITS << (PARELLIZABLE_POSITION << 1);
public static final int STATELESS = SET_BITS << (STATELESS_POSITION << 1);
public static final int GREEDY = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

public static final int KEEP_DISTINCT = SET_BITS << (DISTINCT_POSITION << 1);
public static final int KEEP_SORTED = SET_BITS << (SORTED_POSITION << 1);
public static final int KEEP_SIZED = SET_BITS << (SIZED_POSITION << 1);

private static final int SHORT_CIRCUIT_MASK = SET_BITS << (SHORT_CIRCUIT_POSITION << 1);

// no GREEDY here
private static final int HIGHER_BITS = (PARELLIZABLE | STATELESS | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1;

private static final int STREAM_OP_MASK =
((GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED) << 1) |
GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;

public static String toString(int characteristics) {
return Stream.of(characteristics)
.<String>mapMulti((f, consumer) -> {
if ((f & PARELLIZABLE) == PARELLIZABLE) {
consumer.accept("PARELLIZABLE");
}
if ((f & STATELESS) == STATELESS) {
consumer.accept("STATELESS");
}
if ((f & GREEDY) == GREEDY) {
consumer.accept("GREEDY");
}
if ((f & KEEP_DISTINCT) == KEEP_DISTINCT) {
consumer.accept("KEEP_DISTINCT");
}
if ((f & KEEP_SORTED) == KEEP_SORTED) {
consumer.accept("KEEP_SORTED");
}
if ((f & KEEP_SIZED) == KEEP_SIZED) {
consumer.accept("KEEP_SIZED");
}
})
.collect(Collectors.joining(", "));
}

public static int toOpFlags(int characteristics) {
return ((characteristics ^ SHORT_CIRCUIT_MASK) | HIGHER_BITS) & STREAM_OP_MASK;
}

public static String toOpFlagsString(int opFlags) {
return Arrays.stream(StreamOpFlag.values())
.map(op -> {
if (op.isPreserved(opFlags)) {
return "preserved " + op;
}
if (op.isCleared(opFlags)) {
return "cleared " + op;
}
if (op.isKnown(opFlags)) {
return "set " + op;
}
return "?? " + op;
})
.collect(Collectors.joining(", "));
}

void main() {
var characteristics = PARELLIZABLE | STATELESS | GREEDY | KEEP_DISTINCT | KEEP_SORTED | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics)));

var characteristics2 = STATELESS | KEEP_DISTINCT | KEEP_SIZED;
System.out.println(toOpFlagsString(toOpFlags(characteristics2)));
}
}



Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 16:17
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz" <psandoz at openjdk.java.net>
Sent: Thursday, January 18, 2024 3:36:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
I suspect that it is a rather slippery slope, once KEEP-flags are added, then others will want to be able to have INJECT-flags, and then people might have different opinions w.r.t. the default should be to clear all flags etc.

And that's even before one looks at the composition-part of it, what are the flags for A.andThen(B)? (then extrapolate to N compositions and the available set of flags always approaches 0)

I spent quite a bit of time on this and in the end tracking all this info, and making sure that the flags of implementations correspond to the actual behavior, just ended up costing performance for most streams and introduced an extra dimension to creation and maintenance which I had a hard time justifying.

It can be a slippery slope if we were designing from the ground up but the stream implementation already exists and SORTED, DISTINCT and SIZED are the flags that are already tracked by the current implementation.

Currently only SHORT_CIRCUIT is set (if not greedy),
see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java#L209<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/GathererOp.java*L209__;Iw!!ACWV5N9M2RV99hQ!PhMxqlDzLWPRuwYc7ECRKNPVs0BtnoE-RdT-Jdkng7S-iFuERAHYcWvJ-OMKGLrkPdSrUl3xj1R9ypyeqeWI$>

And for A.andThen(B), A.flags & B.flags should work, the stream is sorted if both gatherers keep it sorted.


Making specific, rare, combinations of operations faster at the expense of making 99% of all others slower is a hard pill for most to swallow.

I suppose that if those flags already exist, it's because they have a purpose and i do not understand how it can make the other operations slower.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Thursday, 18 January 2024 10:28
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Paul Sandoz <psandoz at openjdk.java.net>
Subject: [External] : Re: Gatherer: spliterator characteristics are not propagated



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, January 17, 2024 8:48:07 PM
Subject: Re: Gatherer: spliterator characteristics are not propagated
Hi R?mi,

You can find some of my benches here: https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref<https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_au5zyje2l$>

Initially I had Characteristics such as ORDERED etc on Gatherer but it just didn't end up worth it when looking at the bench results over a wide array of stream sizes and number of operations.

I think there are 3 gatherer characteristics that make sense: KEEP_SORTED, KEEP_DISTINCT and KEEP_SIZED,
all of them say that if the stream was sorted/distinct/sized then the stream returned by a call to gather() is still sorted (with the same comparator), distinct or sized.

As examples, map() is KEEP_SIZED, filter() is KEEP_SORTED | KEEP_DISTINCT and windowFixed is KEEP_DISTINCT.

[CC Paul, so he can correct me if i'm saying something stupid]

Now for the benchmarks, it depends what you want to measure, benchmarking streams is tricky. This is what i know about benchmarking streams.
First, the JIT has two ways to profile types at runtime,
Either a method takes a function as parameter
  void map(Function function) {
    function.apply(...)
  }
and when map is called with a subtype of Function, the JIT will propagate the exact type when map is inlined,
Or a method use a field
  class Op {
    Function function;

    void map() {
       function.apply(...)
    }
  }
in that case, the VM records the profile of function.apply() and if there are more than two different profiles, the VM declare profile poluttion and do not try to optimize.

The Stream implementation tries very hard to use only parameters instead of fields, that's why it does not use classical Iterator that are pull iterator (a filter iterator requires a field) but a Spliterator which is a push iterator, the element is sent as parameter of the consumer.That's also why collect does not use the builder pattern (that accumulate values in fields) but a Collector that publish the functions to be called as parameter.

Obvisously, this is more complex than that, a Collector stores the functions in fields so it should not work well but the implementation uses a record that plays well with escape analysis. Escape analysis see the fields of an instance as parameters so the functions of a Collector are correctly propagated (if the escape analysis works). And lambdas are using invokedynamic, and the VM tries really hard to inline invokedynamic, so lambdas (that captures value or not) are routinely fully inlined with the intermediate operation of a stream.

In your tests, i've not seen comparaisons between an existing method like map() or filter() followed by a sorted()/distinct()/count()/toList(), i.e. operations where the characteristics KEEP_* have an impact and their equivalent using a Gatherer.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Wednesday, 17 January 2024 16:48
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Gatherer: spliterator characteristics are not propagated

While doing some benchmarking of the Gatherer API, i've found that the characteristics of the spliterator was not propagated by the method Stream.gather() making the stream slower than it should.

As an example, there is no way when reimplementing map() using a Gatherer to say that this intermediate operation keep the size, which is important if the terminal operation is toList() because if the size is known, toList() will presize the List and avoid the creation of an intermediary ArrayList.

See https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java<https://urldefense.com/v3/__https://github.com/forax/we_are_all_to_gather/blob/master/src/main/java/com/gihtub/forax/wearealltogather/bench/MapGathererBenchmark.java__;!!ACWV5N9M2RV99hQ!JJy6F9NoL6wKZQK5158up_fTRvH8X7F6JK8T7Euuf8vzbSQbr23eWa9S_yb61ksONVrLrdesCF_auzwTY8aB$>

I think that adding a way to propagate the spliterator characteristics through a Gatherer would greatly improve the performance of commons streams (at least all the ones that end with a call to toList).

I have some idea of how to do that, but I prefer first to hear if i've overlook something and if improving the performance is something worth changing the API.

regards,
R?mi








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240129/2fc1a037/attachment-0001.htm>

From pminborg at openjdk.org  Mon Jan 29 12:35:36 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 29 Jan 2024 12:35:36 GMT
Subject: RFR: 8323159: Consider adding some text re. memory zeroing in
 Arena::allocate [v5]
In-Reply-To: <5jrXFMYPg2eIJUCzZ12yct_g0cwS_1EqXfN8zfer44k=.b8e94df5-6876-4bb0-843e-f0812d5cdb9e@github.com>
References: <Luqp-k8rTFlVmFTRxBybdgKOkTxBEOAEAnga9PFumK8=.0b38f062-b231-4bbd-9fcf-a02a2577450c@github.com>
 <C6pniZ1O0VryRgkxd8VgHf1uy-R89B5GndGR-gBB3Rg=.ae95b271-2a6f-4462-aff7-6a21b8ad0612@github.com>
 <5jrXFMYPg2eIJUCzZ12yct_g0cwS_1EqXfN8zfer44k=.b8e94df5-6876-4bb0-843e-f0812d5cdb9e@github.com>
Message-ID: <-AON96YzAamwtZnAT1yrYgM5O_QXhoZl7_UK8E5tt1o=.f026ad31-31b4-463c-bf30-fea81d482e19@github.com>

On Sun, 28 Jan 2024 00:57:24 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Add test for zero-out
>
> test/jdk/java/foreign/TestScope.java line 150:
> 
>> 148:     }
>> 149: 
>> 150:     private static final MemorySegment ZEROED_MEMORY = MemorySegment.ofArray(new byte[8102]);
> 
> The?nearest power?of?two is?8192?(2<sup>13</sup>):
> Suggestion:
> 
>     private static final MemorySegment ZEROED_MEMORY = MemorySegment.ofArray(new byte[8192]);

Good catch. This was a typo. However, the test works as intended and the PR is already integrated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17308#discussion_r1469525320

From coleenp at openjdk.org  Mon Jan 29 13:47:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 13:47:10 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v5]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Fix some casts unnecessary with nullptr
 - Fix copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/6eb051ed..6ac8aa85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=03-04

  Stats: 32 lines in 27 files changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

PR: https://git.openjdk.org/jdk/pull/17593

From pminborg at openjdk.org  Mon Jan 29 14:03:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 29 Jan 2024 14:03:42 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign [v2]
In-Reply-To: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
Message-ID: <aNJ9r69I5hZkexS2F-tuyfRvjDssrBEujnGxeBfTwuo=.80412909-4197-4948-b57a-1cdb5c3ddfbd@github.com>

> This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Correct path to excluded directory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17403/files
  - new: https://git.openjdk.org/jdk/pull/17403/files/de3b00a7..e00b123d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17403&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17403&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17403/head:pull/17403

PR: https://git.openjdk.org/jdk/pull/17403

From pminborg at openjdk.org  Mon Jan 29 14:03:43 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 29 Jan 2024 14:03:43 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign [v2]
In-Reply-To: <7IXs5Iv1atdt6oh_2Q0oXuq7LZI0AoEvoIfl2sJa5bk=.96edfb45-e4b9-4bea-aeae-758a06f5152f@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
 <MtsPgVmBNjn9nfy9YkEGsnCs8PYVRuVlxZmfaa7YirY=.b4929117-6436-444a-9805-756f1ecf6648@github.com>
 <KAFMo9ebt4Lh5sRAqV5rdUbbqhWPYDJJQ_R9UjMqbe8=.157b9c1a-58a9-4412-9950-119f5a73b3ee@github.com>
 <7IXs5Iv1atdt6oh_2Q0oXuq7LZI0AoEvoIfl2sJa5bk=.96edfb45-e4b9-4bea-aeae-758a06f5152f@github.com>
Message-ID: <9EWvCB5clfxZEvI4-JvCl4IoG1pu9wi1DLI3ga78Qcg=.03a6985e-4bbb-4a93-9add-d55c3691c87f@github.com>

On Mon, 15 Jan 2024 13:27:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> If possible, we should simply exclude all files in directories that have `-` (minus sign) in their name; this is the intentional design to prevent javac from compiling those classes as package names cannot include `-`.
>
> I agree that this piecemeal approach is not good. I think there is a JBS enhancement request to filter all "snippet-files" and "javadoc-files" everywhere. But maybe we can make it broader? Filtering on just `-` makes me a bit nervous though; it seems like it could unintentionally break at some point. But maybe filter out all `-files`?

It would be good if snippets were compiled (so that the syntax and correctness are ensured) but not included in shipped artifacts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17403#discussion_r1469634458

From adinn at openjdk.org  Mon Jan 29 14:15:42 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 29 Jan 2024 14:15:42 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
 <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
 <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>
Message-ID: <C6ZCrH9DtLEQqsgUwAlXUJaIgStp_9Yf3P9n3-QsLMU=.f94f2e5d-90d4-4284-a8f4-fd939a2bd11a@github.com>

On Sun, 28 Jan 2024 22:33:01 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> What stops people from supplying a fake instance? Wouldn't you need to "test run" the instance first?

Not necessarily. When the generated API implementation relies on the capabilities of class `Instrumentation` -- such as opening modules -- to implement the invoked operation the obvious answer is that a fake instance just won't work.

However, if you want the implementation to validate an incoming call you can easily arrange for that. For example, provide a method on the agent class that says yes to its own instance and no for any other instances e.g.

    class AgentClass {
      private static Instrumentation myInst = null;
      
      void premain(Instrumentation inst) {
        myInst = inst;
        . . .
      }
      static boolean validate(Instrumentation inst) {
        return myInst != null && inst == myInst;
      }
?     . . .
    }

Method validate can be used to ensure API calls only proceed when invoked by the agent or code that the agent trusts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914771074

From alanb at openjdk.org  Mon Jan 29 14:15:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Jan 2024 14:15:42 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <C6ZCrH9DtLEQqsgUwAlXUJaIgStp_9Yf3P9n3-QsLMU=.f94f2e5d-90d4-4284-a8f4-fd939a2bd11a@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
 <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
 <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>
 <C6ZCrH9DtLEQqsgUwAlXUJaIgStp_9Yf3P9n3-QsLMU=.f94f2e5d-90d4-4284-a8f4-fd939a2bd11a@github.com>
Message-ID: <0mdILE5g2WCORrs1VlB020SXMvah9tMwJ9BUznM75YM=.835e3a50-1f36-4971-90a4-31414aa4229d@github.com>

On Mon, 29 Jan 2024 14:09:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> What stops people from supplying a fake instance? Wouldn't you need to "test run" the instance first?

In passing, Instrumentation was a candidate to be sealed at one point as the only implementations should be in the java.instrument module. I haven't seen any delegating or other implementations but they might exist so we would need to be careful with compatibility.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914776078

From coleenp at openjdk.org  Mon Jan 29 14:26:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 14:26:38 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v5]
In-Reply-To: <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
Message-ID: <o4v044HFH-d92IoeI78R_3gTrDftveooAeF5hl40JNo=.759c3688-f42c-4b21-8508-cdcc9b893819@github.com>

On Mon, 29 Jan 2024 13:47:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix some casts unnecessary with nullptr
>  - Fix copyrights

Thanks Kevin, Kim and David for wading through this.  If there are other changes we can address them separately preserving your eyeballs.  My copyright script was broken so I fixed it.  I'll wait for GHA to make sure I didn't break anything before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17593#issuecomment-1914798074

From winterhalter at openjdk.org  Mon Jan 29 14:29:57 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Mon, 29 Jan 2024 14:29:57 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <6kHfPwdakIRh3eVC19EOf2jP88YZi6ZsC83bur272CI=.8758fd3f-4186-420d-8ff7-edd4d0610a17@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

There's plenty of them in Byte Buddy and I have seen a bunch in other agents.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914804192

From adinn at openjdk.org  Mon Jan 29 14:34:04 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 29 Jan 2024 14:34:04 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
 <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
 <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>
Message-ID: <lvXe_HcwLDsEJVHFdI3bRXvNF8BflBECkcO02oudXy8=.d6b04242-a81d-48a1-8f0c-8d60faa0e7ac@github.com>

On Sat, 27 Jan 2024 05:11:28 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

> Bytecode transformation should not be rocket science, but it progressively is developing in that direction.

Hmm? Bytecode transformation of the JDK runtime implementation is a lot more complicated than your comments seem to acknowledge and, here's the important thing, *it always has been*. You need to remember that instrumenting JDK runtime code involves rebuilding the engine that you are driving while you are in mid-flight. If you think there are few-to-none hidden gotchas involved in doing that then I suggest you are significantly underestimating the opportunity for things to go wrong -- not just when it comes to instrumenting some specific release of OpenJDK but also when it comes to keeping instrumentation working across legacy and future releases, with all the variety of moving parts that the (necessary) development of the platform requires. 

The same observation explains why project Jigsaw was needed. The danger of clients using internal JDK runtime APIs -- especially the core runtime APIs -- is much more subtle than many of the programmers who have routinely relied on it recognize. The biggest threat is that public runtime APIs are often implemented via calls to multiple internal APIs -- which may themselves involve multiple entries and re-entries to the JVM. It has always been (and always will be) the case that an isolated call from a client to an internal API can leave the JDK runtime and/or the JVM in an incoherent state because correct use of that internal API requires a correct sequence of invocations with matched inputs and outputs. It is easy even for OpenJDK developers to fails to get this right, especially when calls involve entry to the JVM. The possibility for a programmer who is not very familiar with the JDK runtime code and the JVM code to get it wrong are significant. Worse, the problems may not manifest 
 immediately or in all cases so the danger can be unapparent until disaster strikes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914812297

From rriggs at openjdk.org  Mon Jan 29 15:45:37 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Jan 2024 15:45:37 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v13]
In-Reply-To: <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
Message-ID: <SFJ-mzDrsb97IqAOifEbPhmIKUW8dcAolCbGRUb4pLo=.30211e30-534b-40c4-be65-105adaf5d04a@github.com>

On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17491#pullrequestreview-1848993761

From jlahoda at openjdk.org  Mon Jan 29 16:18:53 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Jan 2024 16:18:53 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
Message-ID: <8lRWOKmFWcWkgP5XCyXZGacvbtPRdco7AyVyJ4aVhNs=.afbba2a2-6757-4129-965e-f6c4609e8304@github.com>

On Fri, 26 Jan 2024 18:02:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 redundant null check  and introduce a const boolean for unconditionally exact pairs

javac changes look sensible to me - some minor comments inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5040:

> 5038:      *  @param target     Target primitive or reference type
> 5039:      */
> 5040:     public boolean checkUnconditionallyExact(Type source, Type target) {

Maybe something like `isUnconditionallyExact`?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5060:

> 5058:      *  @param targetType       Target type
> 5059:      */
> 5060:     public boolean checkUnconditionallyExactPrimitives(Type selectorType, Type targetType) {

Maybe something like `isUnconditionallyExactPrimitives`?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1799:

> 1797:                             log.error(label.pos(), Errors.UnconditionalPatternAndDefault);
> 1798:                         }  else if (booleanSwitch && constants.containsAll(Set.of(0, 1))) {
> 1799:                             log.error(label.pos(), Errors.UnconditionalPatternAndDefault); // TODO improve error

Maybe file a follow-up to improve the error?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3079:

> 3077: 
> 3078:         // Resolve the exactness method
> 3079:         Symbol ecsym = rs.resolveQualifiedMethod(null,

Minor: better use `rs.resolveInternalMethod` or `this.lookupMethod`, so that the compilation fails more obviously if the method cannot be found.

test/langtools/tools/javac/diags/examples/NotApplicableTypes.java line 21:

> 19:  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> 20:  * or visit www.oracle.com if you need additional information or have any
> 21:  * questions.

The key does not exist any, per my understanding. I would suggest to simply delete the file.

test/langtools/tools/javac/diags/examples/SelectorTypeNotAllowed.java line 24:

> 22:  */
> 23: 
> 24: // key: compiler.err.preview.feature.disabled.plural

The key does not exist any, per my understanding. I would suggest to simply delete the file.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1848712425
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469805646
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469806136
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469614384
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469811642
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469838360
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1469838529

From lancea at openjdk.org  Mon Jan 29 17:01:51 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 29 Jan 2024 17:01:51 GMT
Subject: RFR: 8324632: Update Zlib Data Compression Library to Version 1.3.1
Message-ID: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>

Hi all,

Please review this PR which updates zlib from 1.3 to 1.3.1 in OpenJDK

The [Zlib Data Compression Library](https://github.com/madler/zlib) has released Zlib 1.3.1 on January 24, 2024.

There are a [small number of updates](https://github.com/madler/zlib/compare/v1.3.1..v1.3) between 1.3 and 1.3.1

Mach5 tiers1-3 have run clean

-------------

Commit messages:
 - update zlib to zlib 1.3.1

Changes: https://git.openjdk.org/jdk/pull/17619/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17619&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324632
  Stats: 164 lines in 14 files changed: 82 ins; 35 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/17619.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17619/head:pull/17619

PR: https://git.openjdk.org/jdk/pull/17619

From coleenp at openjdk.org  Mon Jan 29 17:10:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 17:10:42 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v5]
In-Reply-To: <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
Message-ID: <nG_zjtFu6UUgJ4xUOdf5O53odsLpn9a1UCfJsbT-iVQ=.9aaaa73f-b908-4bfa-88bb-d8288ea1e722@github.com>

On Mon, 29 Jan 2024 13:47:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix some casts unnecessary with nullptr
>  - Fix copyrights

macos-aarch64 build failure in GHA appears unrelated, internal testing passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17593#issuecomment-1915186403

From coleenp at openjdk.org  Mon Jan 29 17:10:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 17:10:43 GMT
Subject: Integrated: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <N5ZQ1ViMwFbAI4AUM1smPAoRTHPdo4nMoYS6D_m8mro=.b1ab6e02-7193-435c-a1f9-8cf6696d6bb5@github.com>

On Fri, 26 Jan 2024 16:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

This pull request has now been integrated.

Changeset: a6bdee48
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6bdee48f39993128d8095d40ab417f0102af0f4
Stats:     8218 lines in 750 files changed: 0 ins; 7 del; 8211 mod

8324681: Replace NULL with nullptr in HotSpot jtreg test native code files

Reviewed-by: kevinw, kbarrett, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17593

From alanb at openjdk.org  Mon Jan 29 17:18:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Jan 2024 17:18:35 GMT
Subject: RFR: 8324632: Update Zlib Data Compression Library to Version
 1.3.1
In-Reply-To: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
References: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
Message-ID: <LlquuuVGFyKqPOoL5ruPJIEdx7tdPYGq4mSVTMtjuog=.f65ed686-4032-4e3f-bfce-a2fd5a1b628e@github.com>

On Mon, 29 Jan 2024 16:57:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.3 to 1.3.1 in OpenJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib) has released Zlib 1.3.1 on January 24, 2024.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.3.1..v1.3) between 1.3 and 1.3.1
> 
> Mach5 tiers1-3 have run clean

@LanceAndersen Can you confirm that there are no changes to the 1.3..1.3.1 diffs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17619#issuecomment-1915201608

From iris at openjdk.org  Mon Jan 29 17:21:25 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 29 Jan 2024 17:21:25 GMT
Subject: RFR: 8324632: Update Zlib Data Compression Library to Version
 1.3.1
In-Reply-To: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
References: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
Message-ID: <ojMVq5YK_Vd3c_9tmfjqqmPrttCQDSpzDvKrj-RTOws=.227713b8-dc29-4c73-9ffe-740754c869e3@github.com>

On Mon, 29 Jan 2024 16:57:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.3 to 1.3.1 in OpenJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib) has released Zlib 1.3.1 on January 24, 2024.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.3.1..v1.3) between 1.3 and 1.3.1
> 
> Mach5 tiers1-3 have run clean

I've spot-checked these files against the referenced  diffs between v1.3.1 and v1.3 and confirm that they are as expected.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17619#pullrequestreview-1849300812

From pminborg at openjdk.org  Mon Jan 29 17:24:37 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 29 Jan 2024 17:24:37 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v2]
In-Reply-To: <SRNbpJUz7ZBtRkWq627Fsr2A287Zvu2WwsITJTco-9M=.263e8ccb-4707-4777-8d8a-81a3bf74a529@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <ZTu8tRFAFOnSQMcJ73QHSbWT02D-b0ynG2-hBDYT9m8=.db114fd6-1903-4493-976e-1ee940de55ab@github.com>
 <MquxdkvcIBJlp-pVsWFUBmtml73w5S3SREEyRan45KA=.c6e91302-a946-4f26-ac02-211f7620c7f8@github.com>
 <SRNbpJUz7ZBtRkWq627Fsr2A287Zvu2WwsITJTco-9M=.263e8ccb-4707-4777-8d8a-81a3bf74a529@github.com>
Message-ID: <QFCHWgw1AjUiQ_OAOgEh_RFwlntI7hn-j9coZp4y88U=.0a0710d4-6b2b-4b4b-b226-348311d749e7@github.com>

On Tue, 16 Jan 2024 09:10:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 958:
>> 
>>> 956:             return new LayoutPath.PathElementImpl(PathKind.DEREF_ELEMENT,
>>> 957:                     LayoutPath::derefElement,
>>> 958:                     "*");
>> 
>> It seems that this would result in paths like `a.b*` rather than the `*a.b`, which is correct C syntax.
>
> Correct. Additional logic is needed to form a correct C syntax. It would be possible to provide a method that does this.

We could add such a method under another issue (https://bugs.openjdk.org/browse/JDK-8323746) because it will be much easier to implement it once the contemplated changes for that issue are in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17417#discussion_r1469948399

From pminborg at openjdk.org  Mon Jan 29 17:31:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 29 Jan 2024 17:31:13 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v3]
In-Reply-To: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
Message-ID: <1sIxiWPVLhn-uR73JJP9bHJUqFJLlalHVySIrQpQErI=.286f7164-607e-4a87-812c-3c581a7ad7ec@github.com>

> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
> 
> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.

Per Minborg has updated the pull request with a new target base 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:

 - Rename local variable
 - Merge branch 'master' into layout-path-tostring
 - Rework PathElement:toString
 - Add toString to PathElement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17417/files
  - new: https://git.openjdk.org/jdk/pull/17417/files/83cf10c5..269523b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=01-02

  Stats: 21865 lines in 781 files changed: 12172 ins; 6978 del; 2715 mod
  Patch: https://git.openjdk.org/jdk/pull/17417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17417/head:pull/17417

PR: https://git.openjdk.org/jdk/pull/17417

From lancea at openjdk.org  Mon Jan 29 17:36:24 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 29 Jan 2024 17:36:24 GMT
Subject: RFR: 8324632: Update Zlib Data Compression Library to Version
 1.3.1
In-Reply-To: <LlquuuVGFyKqPOoL5ruPJIEdx7tdPYGq4mSVTMtjuog=.f65ed686-4032-4e3f-bfce-a2fd5a1b628e@github.com>
References: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
 <LlquuuVGFyKqPOoL5ruPJIEdx7tdPYGq4mSVTMtjuog=.f65ed686-4032-4e3f-bfce-a2fd5a1b628e@github.com>
Message-ID: <cjlQ08L5cvdTxa4CIevUSK44KQjgsdkR1_ESD0hKU4M=.ee845eee-fac5-431c-aed0-29603015c78a@github.com>

On Mon, 29 Jan 2024 17:15:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @LanceAndersen Can you confirm that there are no changes to the 1.3..1.3.1 diffs?

@AlanBateman, yes that is correct, there are no OpenJDK specific changes, it is a straight port of the zlib 1.3.1 changes to our implementation

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17619#issuecomment-1915235240

From naoto at openjdk.org  Mon Jan 29 17:37:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Jan 2024 17:37:44 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v13]
In-Reply-To: <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
Message-ID: <Ylpk4jjCiLf-ovlYpkGjsUVTpyL76sQYTRHHNlS7B5o=.f77aba51-829a-4f7a-a09d-435f79103ffa@github.com>

On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17491#pullrequestreview-1849333765

From mcimadamore at openjdk.org  Mon Jan 29 17:41:46 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 29 Jan 2024 17:41:46 GMT
Subject: RFR: 8323621: JDK build should exclude snippet class in
 java.lang.foreign [v2]
In-Reply-To: <aNJ9r69I5hZkexS2F-tuyfRvjDssrBEujnGxeBfTwuo=.80412909-4197-4948-b57a-1cdb5c3ddfbd@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
 <aNJ9r69I5hZkexS2F-tuyfRvjDssrBEujnGxeBfTwuo=.80412909-4197-4948-b57a-1cdb5c3ddfbd@github.com>
Message-ID: <Fm_NlN2IjtVfcMEUqfxqlGjkxh8QeMzx3FM1XCQGTLM=.c6dd2e2b-fd9a-40b3-8af4-3d01c963e01a@github.com>

On Mon, 29 Jan 2024 14:03:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct path to excluded directory

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17403#pullrequestreview-1849345313

From jlaskey at openjdk.org  Mon Jan 29 17:43:46 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 29 Jan 2024 17:43:46 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v13]
In-Reply-To: <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
Message-ID: <9NfUBLPUM4x2sF266Hmu6PGs1vLSDBtJFrI9mHHx04U=.18c4b443-892b-4362-9fef-ea0966bb3f35@github.com>

On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes

Could I get some reviews for the CSR? https://bugs.openjdk.org/browse/JDK-8263262

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17491#issuecomment-1915245775

From mcimadamore at openjdk.org  Mon Jan 29 17:44:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 29 Jan 2024 17:44:43 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v2]
In-Reply-To: <QFCHWgw1AjUiQ_OAOgEh_RFwlntI7hn-j9coZp4y88U=.0a0710d4-6b2b-4b4b-b226-348311d749e7@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <ZTu8tRFAFOnSQMcJ73QHSbWT02D-b0ynG2-hBDYT9m8=.db114fd6-1903-4493-976e-1ee940de55ab@github.com>
 <MquxdkvcIBJlp-pVsWFUBmtml73w5S3SREEyRan45KA=.c6e91302-a946-4f26-ac02-211f7620c7f8@github.com>
 <SRNbpJUz7ZBtRkWq627Fsr2A287Zvu2WwsITJTco-9M=.263e8ccb-4707-4777-8d8a-81a3bf74a529@github.com>
 <QFCHWgw1AjUiQ_OAOgEh_RFwlntI7hn-j9coZp4y88U=.0a0710d4-6b2b-4b4b-b226-348311d749e7@github.com>
Message-ID: <fx7yxkNyguJL2UFIFEjg3W1afnaBHLMmJKC4cDWFVSY=.6555c3a0-79b9-4c4a-a5ae-77cc4e0385fa@github.com>

On Mon, 29 Jan 2024 17:22:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Correct. Additional logic is needed to form a correct C syntax. It would be possible to provide a method that does this.
>
> We could add such a method under another issue (https://bugs.openjdk.org/browse/JDK-8323746) because it will be much easier to implement it once the contemplated changes for that issue are in.

After some more thinking, I think the toString should just mimic the expression used to create the path.
e.g. 
groupElement("foo")
or
sequenceElement()
sequenceElement(2)
sequenceElement(2, 3)
etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17417#discussion_r1469972616

From duke at openjdk.org  Mon Jan 29 19:18:41 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 29 Jan 2024 19:18:41 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v13]
In-Reply-To: <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
 <eRk2o7ytb0MEbgYc6zX0ASfAdrRkZ0Y5tfAwNjEqOt4=.4f81ff2b-3f88-4296-be7f-14d78bfb6de2@github.com>
Message-ID: <zBiWXuBk3ze6rUKWgvCv896SAd67vNyfrDC_9So2-74=.0c00842a-cb61-4743-87ac-75816e96511e@github.com>

On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes

src/java.base/share/classes/java/lang/String.java line 4229:

> 4227:      *     <th scope="row">{@code \u005CuXXXX}</th>
> 4228:      *     <td>Unicode escape</td>
> 4229:      *     <td>single UTF-16 code unit equivalent {@code U+XXXX}<p>multiple 'u' are support per jls 3.3</td>

Suggestion:

     *     <td>single UTF-16 code unit equivalent {@code U+XXXX}<p>multiple 'u' are supported per JLS 3.3</td>

test/jdk/java/lang/String/TranslateEscapes.java line 120:

> 118:         }
> 119:     }
> 120: 

This?method is?unused:
Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1470081472
PR Review Comment: https://git.openjdk.org/jdk/pull/17491#discussion_r1470082839

From jlaskey at openjdk.org  Mon Jan 29 19:26:57 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 29 Jan 2024 19:26:57 GMT
Subject: RFR: JDK-8263261 Extend String::translateEscapes to support
 unicode escapes [v14]
In-Reply-To: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
References: <SbKvq-ZyvHN3kgiqRwYUyAqKbHXeUiHFygaxbd2Oy40=.c3bbf97c-d3f6-4d51-be0a-be2e3c9b14b9@github.com>
Message-ID: <HC5GJAKRoSWEOxPPjoCidVsN5ozenazfotOV_qvKmWY=.633414b5-6c87-4d69-a674-3a02815d83fb@github.com>

> Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage,

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/lang/String/TranslateEscapes.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/String.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17491/files
  - new: https://git.openjdk.org/jdk/pull/17491/files/74707a66..61a3abab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17491&range=12-13

  Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17491/head:pull/17491

PR: https://git.openjdk.org/jdk/pull/17491

From vromero at openjdk.org  Mon Jan 29 20:27:46 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 29 Jan 2024 20:27:46 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
Message-ID: <7kcOKMS7ryi8yOLlyzjgRW7cK0aJzFIQHpqoRsV_sB4=.1caaf2cc-860a-44c3-9180-79b7df7ab7f2@github.com>

On Fri, 26 Jan 2024 18:02:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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 redundant null check  and introduce a const boolean for unconditionally exact pairs

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1849695360

From psandoz at openjdk.org  Mon Jan 29 23:19:55 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 29 Jan 2024 23:19:55 GMT
Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing memory
 segments
Message-ID: <Ig30JJ-7UE1dL7PfmeJOROeM_T6lA-orcGm4T-wVPdE=.cc7787f0-2c63-4932-8529-9957c90c8fa4@github.com>

The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1).

This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments).

The workaround is to call the static method `{T}Vector::fromMemorySegment`.

The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`.

The tests have been conservatively updated to call the species access method were possible in the knowledge that calls the vector access method (the tests were intended to test out of bounds access when compiled by C2).

Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated.

-------------

Commit messages:
 - Merge branch 'master' into v-load-segment-bounds-checks
 - 8324858: [vectorapi] Bounds checking issues when accessing memory segments

Changes: https://git.openjdk.org/jdk/pull/17621/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17621&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324858
  Stats: 165 lines in 39 files changed: 56 ins; 8 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/17621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17621/head:pull/17621

PR: https://git.openjdk.org/jdk/pull/17621

From abimpoudis at openjdk.org  Mon Jan 29 23:53:08 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 29 Jan 2024 23:53:08 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v56]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@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:

  Address review by Jan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/e466cfba..8c27c5c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=54-55

  Stats: 165 lines in 12 files changed: 78 ins; 68 del; 19 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 mbalao at openjdk.org  Tue Jan 30 00:09:54 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 30 Jan 2024 00:09:54 GMT
Subject: RFR: 8315487: Security Providers Filter [v6]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <p2d5YTDfTgDwI8vkrCXPs2Wtv_Dx_4fsK9FYYA6I2qg=.7257b82f-c241-48c0-96c3-3ff5c8d5fc9c@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Support for cipher transformations and JEP alignment
  of the java.security documentation.
  
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/35516004..f015ba87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=04-05

  Stats: 555 lines in 9 files changed: 387 ins; 44 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

PR: https://git.openjdk.org/jdk/pull/15539

From duke at openjdk.org  Tue Jan 30 01:02:49 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Tue, 30 Jan 2024 01:02:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <lvXe_HcwLDsEJVHFdI3bRXvNF8BflBECkcO02oudXy8=.d6b04242-a81d-48a1-8f0c-8d60faa0e7ac@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
 <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
 <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>
 <lvXe_HcwLDsEJVHFdI3bRXvNF8BflBECkcO02oudXy8=.d6b04242-a81d-48a1-8f0c-8d60faa0e7ac@github.com>
Message-ID: <rZ2TyCYxB7JqMY1RDUGGrQbMywllrhX8QftJ7NqeVIk=.6885eb39-425c-423c-9d7d-2f4e2efebb24@github.com>

On Mon, 29 Jan 2024 14:31:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> > Bytecode transformation should not be rocket science, but it progressively is developing in that direction.
> 
> Hmm? Bytecode transformation of the JDK runtime implementation is a lot more complicated than your comments seem to acknowledge

That is, because I was not talking about JDK runtime transformation but about what the AspectJ weaving agent does: transformation of application classes during class-loading.

I am aware of the fact, that it is also possible to retransform already loaded classes, as a special case also bootstrap ones from the JRE. Of course, this is more complicated than the simple case. But my point was, that even the simple case is not simple, if I need to define classes in an arbitrary class loader - not because technically it is difficult, but simply because the JRE API to do so is more and more sealed off with each new Java release. This is also what I mean, when I said, that developers are not treated as adults but "protected" by well-meaning, but ill-doing helicopter parents.

> here's the important thing, _it always has been_.

No, byte code transformation is not complicated per se. Getting the transformed classes where they need to be is complicated, but artificially so.

> You need to remember that instrumenting JDK runtime code involves rebuilding the engine that you are driving while you are in mid-flight.

No, I do not need to remember, because I am aware of that fact. It is just off-topic here with regard to what I asked about. But that other use case, which I have experimented with in another context (test mocking and stubbing) in the past, is an intriguing one, too. I am not underestimating anything there, but for AspectJ it is simply out of scope. Should I ever decide to add the capability to weave aspects into JRE classes, of course that will up the complexity by a notch or two.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1915860036

From duke at openjdk.org  Tue Jan 30 02:01:41 2024
From: duke at openjdk.org (duke)
Date: Tue, 30 Jan 2024 02:01:41 GMT
Subject: Withdrawn: 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: <8xIZ6lBaroeGU4SYJ2EHufI6MC8HcLoC8gIKqWlYk5w=.28d3c17c-5bd6-4abf-80cf-086583c4775f@github.com>

On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bj?rsn?s <eirbjo 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"

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16952

From jpai at openjdk.org  Tue Jan 30 05:37:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 05:37:44 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: <WAEbjqx3d5sYpkfzDGzKSs0ZKEUTtXqJvA_6Va2qD-g=.32ff1b84-3539-4edd-beba-bc9de26fc778@github.com>

On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bj?rsn?s <eirbjo 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"

Hello Eirik, I think this is a reasonable change. I haven't had a chance to review some of these PRs due to some other priority tasks. I have these PRs on my TODO list. So if you want to pursue this further, please go ahead and reopen this and I'll review this in the coming days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1916110895

From alanb at openjdk.org  Tue Jan 30 07:52:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Jan 2024 07:52:31 GMT
Subject: RFR: 8324632: Update Zlib Data Compression Library to Version
 1.3.1
In-Reply-To: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
References: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
Message-ID: <j4p0eZw3yx6ub-0HQeezQC8Py2cNyhX9ABm5MP_xkwA=.48c7e8fd-5451-4cf7-a952-a556fb8c485e@github.com>

On Mon, 29 Jan 2024 16:57:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.3 to 1.3.1 in OpenJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib) has released Zlib 1.3.1 on January 24, 2024.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.3.1..v1.3) between 1.3 and 1.3.1
> 
> Mach5 tiers1-3 have run clean

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17619#pullrequestreview-1850429347

From abimpoudis at openjdk.org  Tue Jan 30 08:33:49 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 30 Jan 2024 08:33:49 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v55]
In-Reply-To: <8lRWOKmFWcWkgP5XCyXZGacvbtPRdco7AyVyJ4aVhNs=.afbba2a2-6757-4129-965e-f6c4609e8304@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <fE7sD6DjCNvcbnkwIJ0r_3VGhSLAAAcC0RCzn-EnqpQ=.49f2c838-186a-411a-9c39-1b077e4f8c07@github.com>
 <8lRWOKmFWcWkgP5XCyXZGacvbtPRdco7AyVyJ4aVhNs=.afbba2a2-6757-4129-965e-f6c4609e8304@github.com>
Message-ID: <bpXeJbYfnvP2tE__FpNpsGTPnElofZejaxtGu1yaf0k=.8f971547-c238-4c01-a7d3-52a0dc2b5890@github.com>

On Mon, 29 Jan 2024 16:16:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>
> javac changes look sensible to me - some minor comments inline.

Thx for all the comments @lahodaj @mcimadamore @vicente-romero-oracle @rgiulietti @jddarcy ? 

Addressed all @lahodaj

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1916314623

From mbaesken at openjdk.org  Tue Jan 30 09:13:02 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 30 Jan 2024 09:13:02 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
Message-ID: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>

On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
Of course this has the downside that on very large machines the concurrent execution is not done any more.

-------------

Commit messages:
 - JDK-8324930

Changes: https://git.openjdk.org/jdk/pull/17625/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324930
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17625/head:pull/17625

PR: https://git.openjdk.org/jdk/pull/17625

From jlahoda at openjdk.org  Tue Jan 30 10:07:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 Jan 2024 10:07:28 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v56]
In-Reply-To: <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
Message-ID: <WAk8Ci4cciAoqnBZQeSyF9f3UI1bHc2XxOfOMhd0S60=.81692780-c81e-479c-a495-c9a2747fbb59@github.com>

On Mon, 29 Jan 2024 23:53:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Address review by Jan

lgtm

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1850754613

From dfuchs at openjdk.org  Tue Jan 30 14:01:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:01:24 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:

> 347:     @SuppressWarnings("removal")
> 348:     private Subject getSubject() {
> 349:         return Subject.current();

Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:

> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
> 306:                     public Subject run() {
> 307:                         return Subject.current();

Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471257982
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471263581

From jkratochvil at openjdk.org  Tue Jan 30 14:10:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 30 Jan 2024 14:10:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v4]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <I3BAK5YV_kYAMzAsfS10Mojb1BTv92wxAfHqFEtYY5Y=.965713f7-1a03-452b-b78d-ee59f2875722@github.com>

> The testcase requires root permissions.

Jan Kratochvil has updated the pull request with a new target base 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:

 - Fix test/jdk/jdk/internal/platform/cgroup/ testcases regression
 - Fix cgroup1 hierarchical limit reading
 - Fix the testcase for cgroup1
 - NestedCgroup: Better error reporting
 - Merge branch 'master' into master-cgroup
 - Merge branch 'master' into master-cgroup
 - Fix gtest testcases compilation errors
 - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected
 - 4c556a78: <no commit message found>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/ae58f7e3..dcb46c59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=02-03

  Stats: 109 lines in 9 files changed: 35 ins; 28 del; 46 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 jkratochvil at openjdk.org  Tue Jan 30 14:10:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 30 Jan 2024 14:10:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: <QZ94TIavipCvrdj9KK8D549F8MCpsg4tY5p3Rmhmrs8=.39b18198-e69a-466b-9890-57437fe41491@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
 <QZ94TIavipCvrdj9KK8D549F8MCpsg4tY5p3Rmhmrs8=.39b18198-e69a-466b-9890-57437fe41491@github.com>
Message-ID: <PJMpAmzn5viGJrlt2uQYcNnc3TnQ0HaBgZyIQR2i0uc=.8f277472-c071-4145-899b-e51001347362@github.com>

On Fri, 12 Jan 2024 16:26:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtest testcases compilation errors
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 97:
> 
>> 95: 
>> 96:         List<String> cgcreate = new ArrayList<>();
>> 97:         cgcreate.add("cgcreate");
> 
> This test relies on `cgcreate` being present on the test system. I wonder if we could create a similar test with using `systemd-slices`  only. Either way, we need to have a corresponding check that this test dependency is there a. la. `@requires docker`.

`cgcreate` is in `libcgroup-tools`, that is unrelated to `docker`. I have implemented a check for its (or rather `cgdelete`) existence.

> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 112:
> 
>> 110:         if (!matcher.find()) {
>> 111:             System.err.println(mountInfo);
>> 112:             throw new SkippedException("cgroup2 filesystem mount point not found");
> 
> Why is this check there? It should be the same for hierachical cgroup v1 systems (most of them), no? My testing of the `cgcreate` flow suggests it's the same on `v1`. It's just not as visible since there are per controller paths in `/proc/self/cgroup` on `v1` and we have the hierarchical memory limit work-around employed on v1.

This should be fixed now with the new cgroup1 support.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1471281953
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1471280268

From jkratochvil at openjdk.org  Tue Jan 30 14:12:53 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 30 Jan 2024 14:12:53 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v5]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <-u3JvukozKlWhWAMPT4S2_-r32A4WGlwvluP515P29o=.1c6f2de4-b580-4f63-b70f-f8d449480164@github.com>

> The testcase requires root permissions.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded jdk.test.lib.helpers.ClassFileInstaller

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/dcb46c59..0c912965

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 dfuchs at openjdk.org  Tue Jan 30 14:21:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:32 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <K4rNAdIWeAQ1YRVn-4-H96Aj6nZ9JCk0vQRbwcivKo8=.3acbb46f-0d68-4904-aeac-a98a16b04e8f@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Changes requested by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1851409950

From dfuchs at openjdk.org  Tue Jan 30 14:21:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:33 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>

On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:         return Subject.current();
> 
> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:

`RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 

So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?

It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.

Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471308151

From eirbjo at openjdk.org  Tue Jan 30 16:17:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 30 Jan 2024 16:17:13 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v2]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@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"

Eirik Bj?rsn?s has updated the pull request with a new target base 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:

 - Update copyright years for 2024
 - Merge branch 'master' into zipentry-external-attributes
 - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16952/files
  - new: https://git.openjdk.org/jdk/pull/16952/files/87db8646..481ae754

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=00-01

  Stats: 155690 lines in 2884 files changed: 86094 ins; 58372 del; 11224 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 weijun at openjdk.org  Tue Jan 30 16:48:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:48:53 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
Message-ID: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>

On Tue, 30 Jan 2024 14:19:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
>> 
>>> 347:     @SuppressWarnings("removal")
>>> 348:     private Subject getSubject() {
>>> 349:         return Subject.current();
>> 
>> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.
>
> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
> 
> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
> 
> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
> 
> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
> 
> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

This is complicated.

The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.

I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.

I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471591997

From pminborg at openjdk.org  Tue Jan 30 16:58:35 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 30 Jan 2024 16:58:35 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v4]
In-Reply-To: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
Message-ID: <D_2mDmmrANf1pZylO4ev3sPnLpgcHpBFeQEUANnOSTs=.8f336c74-0964-4b53-b984-a839395f0141@github.com>

> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
> 
> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework the LayoutPath::toString output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17417/files
  - new: https://git.openjdk.org/jdk/pull/17417/files/269523b8..41c5a602

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17417&range=02-03

  Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/17417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17417/head:pull/17417

PR: https://git.openjdk.org/jdk/pull/17417

From weijun at openjdk.org  Tue Jan 30 16:44:46 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:44:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>

On Tue, 30 Jan 2024 13:56:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
> 
>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>> 306:                     public Subject run() {
>> 307:                         return Subject.current();
> 
> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471585097

From jvernee at openjdk.org  Tue Jan 30 17:17:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 30 Jan 2024 17:17:37 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v4]
In-Reply-To: <D_2mDmmrANf1pZylO4ev3sPnLpgcHpBFeQEUANnOSTs=.8f336c74-0964-4b53-b984-a839395f0141@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <D_2mDmmrANf1pZylO4ev3sPnLpgcHpBFeQEUANnOSTs=.8f336c74-0964-4b53-b984-a839395f0141@github.com>
Message-ID: <dR3-Wgj1QUscSimvxXXPRR_HO5HmPl_imdoFkdw31ao=.499013e8-2028-4f87-a7c4-9b43d600c521@github.com>

On Tue, 30 Jan 2024 16:58:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
>> 
>> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework the LayoutPath::toString output

I like the latest approach. It leans on familiar names/syntax. I think that will be more intuitive than mimicking C syntax.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17417#pullrequestreview-1851899390

From shade at openjdk.org  Tue Jan 30 17:23:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Jan 2024 17:23:31 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
References: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
Message-ID: <QoS00-jNWBQeQ0UaTKSs6hwnGCnT1zD0GvoS9FNBEac=.23031fd7-1b0c-43b8-bbc5-a6fa02b75661@github.com>

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Can we maybe see if we can fix these tests without exclusive-accessing them? I find it surprising that `java/lang/StringBuilder` tests are problematic, but `java/lang/StringBuffer` tests are not. Which tests fail?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17625#pullrequestreview-1851921699

From acobbs at openjdk.org  Tue Jan 30 18:28:32 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 30 Jan 2024 18:28:32 GMT
Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent
 MessageFormat pattern [v7]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <ghqNTUFsoUYlbXazYygGZV7VZ3tlOj_z9tNLR4EDUSQ=.04239c7d-4747-428a-bc13-8e7a5f171b43@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Fix misspelling in comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/a4d82c67..76e3d6ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

PR: https://git.openjdk.org/jdk/pull/17416

From jpai at openjdk.org  Tue Jan 30 19:33:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 19:33:10 GMT
Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo
Message-ID: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>

Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

-------------

Commit messages:
 - 8271147: java/nio/file/Path.java javadoc typo

Changes: https://git.openjdk.org/jdk/pull/4884/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8271147
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/4884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/4884/head:pull/4884

PR: https://git.openjdk.org/jdk/pull/4884

From iris at openjdk.org  Tue Jan 30 19:33:10 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 Jan 2024 19:33:10 GMT
Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo
In-Reply-To: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>
References: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>
Message-ID: <qZXvMfFXBwYPYN2Vqie1g7Sd6pw0gsi6FUirmoesde0=.b1773da3-0ac7-420b-a9ff-01139194fe37@github.com>

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/4884#pullrequestreview-713382247

From jpai at openjdk.org  Tue Jan 30 19:33:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 19:33:10 GMT
Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo
In-Reply-To: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>
References: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>
Message-ID: <TSRVQCf-7JlAueOj6bucPtXXBueZDLcdr2PoL8jfj1k=.a67b21aa-776f-4425-b64e-7be7b6f96f1a@github.com>

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

Thank you for the review, Iris.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/4884#issuecomment-885383972

From jpai at openjdk.org  Tue Jan 30 19:33:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 19:33:10 GMT
Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo
In-Reply-To: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>
References: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.ded509b9-1e4a-4f98-b76c-ef5b786b004e@github.com>
Message-ID: <GaOK3kVWdRyJojbZWqEGmXVk6WtrnIJuqS3TCsomwuc=.6cbeb758-4544-47cb-b2ec-7e5cb1a87b1f@github.com>

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

This pull request has now been integrated.

Changeset: 8156ff60
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8156ff609b27316f31ba89d9eb8ca752f4027c2b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271147: java/nio/file/Path.java javadoc typo

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/4884

From eirbjo at openjdk.org  Tue Jan 30 20:07:57 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 30 Jan 2024 20:07:57 GMT
Subject: RFR: 8324998: Add test cases for String.regionMatches comparing Turkic
 dotted/dotless I with uppercase latin I
Message-ID: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>

Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 

The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.

This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

-------------

Commit messages:
 - Update copyright year
 - Add test coverage for regionMatches of Turkic dotted I / dotless i against LATIN CAPITAL LETTER I

Changes: https://git.openjdk.org/jdk/pull/17639/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324998
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17639/head:pull/17639

PR: https://git.openjdk.org/jdk/pull/17639

From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v2]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <lvRruRgRq_fjDZkadDnMl1l2mbn6riSOew16WnNQrok=.dc8a4d37-2300-4223-aaab-ea81ae8f7223@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - JMX needs SM
 - Resolve Alan's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/75df9b0d..a16472fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=00-01

  Stats: 89 lines in 10 files changed: 36 ins; 16 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472

From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v2]
In-Reply-To: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
 <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
Message-ID: <HRBW0RxGY38lLNj0o0sFguRZ8nYqLjJMVZ2jQoxZkN0=.906bccdf-5e24-4449-a142-1a40491ffd13@github.com>

On Tue, 30 Jan 2024 16:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
>> 
>> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
>> 
>> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
>> 
>> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
>> 
>> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.
>
> This is complicated.
> 
> The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.
> 
> I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.
> 
> I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

A new commit is push. The change in this class is reverted. I'm still investigating the other one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471906073

From darcy at openjdk.org  Tue Jan 30 21:15:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 Jan 2024 21:15:36 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v56]
In-Reply-To: <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <CWbof342i2wSpBaMHTso27d3Gc70hVLisGj2fFWejOc=.924cb0ea-48e9-4a29-ad9c-167a2b20b94c@github.com>
Message-ID: <NlAdd_aRh0FyDnkSEKMLuhppVwiGx8RdxCDn-svUTw8=.82eb9cf5-bfe6-4b02-a51f-de28031bf44f@github.com>

On Mon, 29 Jan 2024 23:53:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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:
> 
>   Address review by Jan

test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 46:

> 44:  * @test
> 45:  * @bug 8304487
> 46:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

While the bug synopsis isn't off-topic for the summary, the summary could be more informative, something like:
"Verify boundary and special cases of exact conversion predicates", etc.

test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 65:

> 63:     }
> 64: 
> 65:     public static void testByte() {

If this test had the likelihood of needing to be updated, I would recommend some kind of refactoring so that the implicit loops ("for each of these boundary values in type T..") were explicit, but given that the test should not need to be updated often, I think the current approach is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1471963476
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1471968497

From jlu at openjdk.org  Tue Jan 30 21:23:56 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Jan 2024 21:23:56 GMT
Subject: RFR: JDK-6285888: ChoiceFormat can support unescaped relational
 symbols in the Format segment
Message-ID: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.

Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.

For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.

Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.

-------------

Commit messages:
 - update PatternsTest
 - more accurately define the SubPattern note
 - init

Changes: https://git.openjdk.org/jdk/pull/17640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6285888
  Stats: 210 lines in 3 files changed: 144 ins; 59 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17640/head:pull/17640

PR: https://git.openjdk.org/jdk/pull/17640

From duke at openjdk.org  Tue Jan 30 21:41:49 2024
From: duke at openjdk.org (Hans Boehm)
Date: Tue, 30 Jan 2024 21:41:49 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v7]
In-Reply-To: <f7xiLmhBedF-ZWjCwx0cDlwLSmZPK76Be-XnTMPN5Ug=.75563fb4-07a4-43e6-a757-f4a7a66479b2@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <f7xiLmhBedF-ZWjCwx0cDlwLSmZPK76Be-XnTMPN5Ug=.75563fb4-07a4-43e6-a757-f4a7a66479b2@github.com>
Message-ID: <08WIXF8evpw7ZRGFOwA39Xiop2X7epEE0G6_wX3Foo4=.01d3af7d-776b-4c05-9f81-25bbd3b2194d@github.com>

On Thu, 25 Jan 2024 23:09:51 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 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:
> 
>   Updates to clear() and enqueue()

src/java.base/share/classes/java/lang/ref/package-info.java line 104:

> 102:  * <ul>
> 103:  *
> 104:  * <li> Actions in a thread prior to calling

Is line 104 needed? Can we just say that Refrence.reachaboilityFence(x) happens-before ...

src/java.base/share/classes/java/lang/ref/package-info.java line 109:

> 107:  *
> 108:  * <li>The clearing of a reference by the garbage collector <i>happens-before</i>
> 109:  * the garbage collector enqueues the reference.</li>

Is it worth specifying this middle step? Is there a way to tell that something has been enqueued without removing the reference or calling the deprecated (and very dubious) isEnqueued method? Could we just remove this paragraph, and instead start the next one with "The clearing of a reference by the garbage collector ..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1406790434
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1406865525

From weijun at openjdk.org  Tue Jan 30 21:58:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 21:58:28 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fix MBeanServerFileAccessController, more test in SM

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/a16472fb..8f270d09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=01-02

  Stats: 18 lines in 2 files changed: 8 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472

From weijun at openjdk.org  Tue Jan 30 22:36:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 22:36:47 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
Message-ID: <QRKZc0wq2LKmqFG9rnq3h92fu3Y-u-78gYcsAlnxm2M=.436b9a55-bb43-4026-84ab-c9c3ae35e1f9@github.com>

On Tue, 30 Jan 2024 16:41:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
>> 
>>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>>> 306:                     public Subject run() {
>>> 307:                         return Subject.current();
>> 
>> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?
>
> When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

I fixed it in the latest commit. The original code change is simply wrong. `AccessController.getContext()` would return different ACCs inside and outside `doPriv`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1472043888

From naoto at openjdk.org  Tue Jan 30 22:41:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 30 Jan 2024 22:41:42 GMT
Subject: RFR: JDK-6285888: ChoiceFormat can support unescaped relational
 symbols in the Format segment
In-Reply-To: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
Message-ID: <6zMszAL4vLbJXR6deHIGtCaMyrbPgRqOIWjibkJwB64=.021e48d0-b906-4378-95cf-8a1e286a1c79@github.com>

On Tue, 30 Jan 2024 21:19:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.
> 
> Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.
> 
> For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.
> 
> Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.

src/java.base/share/classes/java/text/ChoiceFormat.java line 185:

> 183:  * it must be single quoted. For example,
> 184:  * {@code new ChoiceFormat("1# '#'1 ").format(1)} returns {@code " #1 "}.
> 185:  * Use two single quotes in a row to produce a literal single quote. For example,

It sounds right to remove this restriction, but if we were to use `|` inside `Format`, shouldn't it still need to be single-quoted?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17640#discussion_r1472064667

From naoto at openjdk.org  Tue Jan 30 22:49:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 30 Jan 2024 22:49:41 GMT
Subject: RFR: 8324998: Add test cases for String.regionMatches comparing
 Turkic dotted/dotless I with uppercase latin I
In-Reply-To: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
References: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
Message-ID: <KKKK9stCjzh0NYbF7VtVZKzDG5ngfYXJUWFsUjPloTE=.21df0230-519a-410f-839f-7ef4d20e51d4@github.com>

On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 
> 
> The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.
> 
> This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

Looks reasonable to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17639#pullrequestreview-1852521752

From bchristi at openjdk.org  Tue Jan 30 22:51:34 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 30 Jan 2024 22:51:34 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v7]
In-Reply-To: <ZCVg3uGcRf3a8Tn8Sgh2Bu2rxUoFATI8NB1_A9O9MMo=.a5c6d9df-c982-4e1f-add7-d38f52cd1cb3@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <ZCVg3uGcRf3a8Tn8Sgh2Bu2rxUoFATI8NB1_A9O9MMo=.a5c6d9df-c982-4e1f-add7-d38f52cd1cb3@github.com>
Message-ID: <2pas3-zqLGFhOAbUkV8ZQhDaZpDJtF4HN6pFrVHCWao=.4406f0f9-7a84-4516-89ec-3b0ce551bff0@github.com>

On Mon, 27 Nov 2023 22:33:16 GMT, Hans Boehm <duke at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates to clear() and enqueue()
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 546:
> 
>> 544:      * <a href="package-summary.html#reachability"><em>strongly reachable</em></a>,
>> 545:      * regardless of any other actions of the program that might otherwise cause
>> 546:      * the object to become unreachable; thus, the object is not
> 
> Delete "regardless of any other actions of the program that might otherwise cause the object to become unreachable" ? I have no idea what actions would qualify there. And it's more misleading thann informative, since IMO the real concern here is compiler dead variable elimination.

The only action I can think of would be nulling out the last strong reference to the object in question.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1472074132

From jlu at openjdk.org  Tue Jan 30 23:09:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Jan 2024 23:09:17 GMT
Subject: RFR: JDK-6285888: ChoiceFormat can support unescaped relational
 symbols in the Format segment [v2]
In-Reply-To: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
Message-ID: <KpSLzTox6u1ecpTC_z8jxHv6OeFYcQcdny_ghXL1V1A=.8b637d59-dd46-49a4-b098-35b6ea564178@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.
> 
> Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.
> 
> For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.
> 
> Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  update wording on quoting behavior

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17640/files
  - new: https://git.openjdk.org/jdk/pull/17640/files/a088f91f..740686b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17640&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17640&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17640/head:pull/17640

PR: https://git.openjdk.org/jdk/pull/17640

From jlu at openjdk.org  Tue Jan 30 23:09:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Jan 2024 23:09:17 GMT
Subject: RFR: JDK-6285888: ChoiceFormat can support unescaped relational
 symbols in the Format segment [v2]
In-Reply-To: <6zMszAL4vLbJXR6deHIGtCaMyrbPgRqOIWjibkJwB64=.021e48d0-b906-4378-95cf-8a1e286a1c79@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
 <6zMszAL4vLbJXR6deHIGtCaMyrbPgRqOIWjibkJwB64=.021e48d0-b906-4378-95cf-8a1e286a1c79@github.com>
Message-ID: <XPCcZA9Rtbl0davyA-c-Nnf8rpLtk5c1M8N0MM-nTbo=.22d74b99-a5b0-4c7d-99bc-27800687a8d7@github.com>

On Tue, 30 Jan 2024 22:36:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update wording on quoting behavior
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 185:
> 
>> 183:  * <p>
>> 184:  * For more sophisticated patterns, {@code ChoiceFormat} can be used with
>> 185:  * {@link MessageFormat} to produce accurate forms for singular and plural:
> 
> It sounds right to remove this restriction, but if we were to use `|` inside `Format`, shouldn't it still need to be single-quoted?

Right, the restriction shouldn't be removed, but rather updated. Fixed in https://github.com/openjdk/jdk/pull/17640/commits/740686b2052a276b77529bea5444692e5bbe0078

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17640#discussion_r1472075577

From iris at openjdk.org  Tue Jan 30 23:12:30 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 Jan 2024 23:12:30 GMT
Subject: RFR: 8324998: Add test cases for String.regionMatches comparing
 Turkic dotted/dotless I with uppercase latin I
In-Reply-To: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
References: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
Message-ID: <xKkTCExB2_rwGi33fz1-wFvnmLa5S1fShd3G_xtrkT0=.db798137-4872-4c36-86b3-40dc198e155a@github.com>

On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 
> 
> The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.
> 
> This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17639#pullrequestreview-1852564646

From eirbjo at openjdk.org  Tue Jan 30 23:56:10 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 30 Jan 2024 23:56:10 GMT
Subject: Integrated: 8324998: Add test cases for String.regionMatches comparing
 Turkic dotted/dotless I with uppercase latin I
In-Reply-To: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
References: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
Message-ID: <x3GVivajet_402tCaJJH8PvZZONI1CZKUanoXOiOvCU=.2eab5023-5cd7-482c-94bf-6ccf11cabd23@github.com>

On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 
> 
> The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.
> 
> This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

This pull request has now been integrated.

Changeset: c3c1d5bd
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3c1d5bd12f80c6a720e431961e90b09c2d972f9
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8324998: Add test cases for String.regionMatches comparing Turkic dotted/dotless I with uppercase latin I

Reviewed-by: naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/17639

From mcimadamore at openjdk.org  Wed Jan 31 00:10:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 Jan 2024 00:10:01 GMT
Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing
 memory segments
In-Reply-To: <Ig30JJ-7UE1dL7PfmeJOROeM_T6lA-orcGm4T-wVPdE=.cc7787f0-2c63-4932-8529-9957c90c8fa4@github.com>
References: <Ig30JJ-7UE1dL7PfmeJOROeM_T6lA-orcGm4T-wVPdE=.cc7787f0-2c63-4932-8529-9957c90c8fa4@github.com>
Message-ID: <ulPEK86-fRiUPbPT3dsR2xpoRQe3ASKdCbrZil71zNE=.687b6841-b48d-4366-8545-cc4462e52ea9@github.com>

On Mon, 29 Jan 2024 19:45:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1).
> 
> This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments).
> 
> The workaround is to call the static method `{T}Vector::fromMemorySegment`.
> 
> The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`.
> 
> The tests have been conservatively updated to call the species access method where possible in the knowledge that it calls the vector access method (the tests were intended to test out of bounds access when compiled by C2).
> 
> Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated.

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17621#pullrequestreview-1852643438

From mcimadamore at openjdk.org  Wed Jan 31 00:13:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 Jan 2024 00:13:01 GMT
Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing
 memory segments
In-Reply-To: <Ig30JJ-7UE1dL7PfmeJOROeM_T6lA-orcGm4T-wVPdE=.cc7787f0-2c63-4932-8529-9957c90c8fa4@github.com>
References: <Ig30JJ-7UE1dL7PfmeJOROeM_T6lA-orcGm4T-wVPdE=.cc7787f0-2c63-4932-8529-9957c90c8fa4@github.com>
Message-ID: <JikZeOonhon0qfzq4AKM5PJFQpIU_57e_alOg8yHPOA=.821f9845-fb01-468a-bbdc-e6b343972630@github.com>

On Mon, 29 Jan 2024 19:45:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1).
> 
> This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments).
> 
> The workaround is to call the static method `{T}Vector::fromMemorySegment`.
> 
> The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`.
> 
> The tests have been conservatively updated to call the species access method where possible in the knowledge that it calls the vector access method (the tests were intended to test out of bounds access when compiled by C2).
> 
> Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated.

test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template line 271:

> 269:     @DontInline
> 270:     static $abstractvectortype$ fromArray($type$[] a, int i) {
> 271:         return ($abstractvectortype$) SPECIES.fromArray(a, i);

These new tests focus on the species method - but should we also test the statics factories in the record class, just in case a regression is introduced and the two implementation start diverging again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17621#discussion_r1472143425

From psandoz at openjdk.org  Wed Jan 31 00:37:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 31 Jan 2024 00:37:02 GMT
Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing
 memory segments
In-Reply-To: <JikZeOonhon0qfzq4AKM5PJFQpIU_57e_alOg8yHPOA=.821f9845-fb01-468a-bbdc-e6b343972630@github.com>
References: <Ig30JJ-7UE1dL7PfmeJOROeM_T6lA-orcGm4T-wVPdE=.cc7787f0-2c63-4932-8529-9957c90c8fa4@github.com>
 <JikZeOonhon0qfzq4AKM5PJFQpIU_57e_alOg8yHPOA=.821f9845-fb01-468a-bbdc-e6b343972630@github.com>
Message-ID: <U1_6uXGGiNeS01iTUNwOInPBT7jBiLcWSNMtNt5K01g=.4cdd7a48-9826-4924-948d-c05163058430@github.com>

On Wed, 31 Jan 2024 00:10:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1).
>> 
>> This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments).
>> 
>> The workaround is to call the static method `{T}Vector::fromMemorySegment`.
>> 
>> The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`.
>> 
>> The tests have been conservatively updated to call the species access method where possible in the knowledge that it calls the vector access method (the tests were intended to test out of bounds access when compiled by C2).
>> 
>> Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated.
>
> test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template line 271:
> 
>> 269:     @DontInline
>> 270:     static $abstractvectortype$ fromArray($type$[] a, int i) {
>> 271:         return ($abstractvectortype$) SPECIES.fromArray(a, i);
> 
> These new tests focus on the species method - but should we also test the statics factories in the record class, just in case a regression is introduced and the two implementation start diverging again?

My expectation is the risk is small, but of course non-zero. These tests can be expensive to run so i was trying balance the risk without increasing test execution times.

I could strengthen the comment from:

        @ForceInline
        @Override final
        public ByteVector fromMemorySegment(MemorySegment ms, long offset, ByteOrder bo) {
            // User entry point:  Be careful with inputs.
            return ByteVector
                .fromMemorySegment(this, ms, offset, bo);
        }


to:


        @ForceInline
        @Override final
        public ByteVector fromMemorySegment(MemorySegment ms, long offset, ByteOrder bo) {
            // User entry point
            // Defer only to the equivalent method on the vector class, using the same inputs
            return ByteVector
                .fromMemorySegment(this, ms, offset, bo);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17621#discussion_r1472162760

From bchristi at openjdk.org  Wed Jan 31 00:40:07 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 31 Jan 2024 00:40:07 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v7]
In-Reply-To: <-EMuHypBSxQF40bnTvD13GKpGbx59CRml904UB6owkc=.c173d608-9e4e-4455-aab2-d0327733f236@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <uzQSfsy_x8aOwxjnB3XzNXu5Cg_8keIYz_6_NZVELiw=.cd4ca6f8-347a-416e-8722-84e47a4b2329@github.com>
 <-EMuHypBSxQF40bnTvD13GKpGbx59CRml904UB6owkc=.c173d608-9e4e-4455-aab2-d0327733f236@github.com>
Message-ID: <NK1LqKI8MfPYYVFqmtWXTaQcCTJg5cd7EVeTBXJgXbg=.53f8a3c5-2457-4a3c-a82e-6c3d1bbc3e47@github.com>

On Thu, 30 Nov 2023 22:39:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> IMO, the core of the semantics here are that the reachabilityFence() call happens before clearing or enqueueing of any References to the argument. I think it's the call itself, not the end of the argument.s scope (which may not even make sense) that matters here.
>> 
>> Perhaps reachabilityFence(x) should also happen before any objects that are definitely reachable from x (JLS 12.6.2) at that point are cleared or enqueued. That is not completely clear to me, since it impacts the legality of dead field elimination. And it would be nice to get rid of 12.6.2.
>
> The existing docs refer to "invocation" of this method. I've continued with that, and in general have kept this at a bit higher level, in order to simplify understanding.
> 
> I'm open to more detailed wording, if it would improve understandability, (or if what I have is not functionally accurate).

> Perhaps reachabilityFence(x) should also happen before any objects that are definitely reachable from x (JLS 12.6.2) at that point are cleared or enqueued.

I don't think we need to extend this to objects reachable from x.

Consider what I consider to be the primary scenario - x has resources to cleanup after it becomes unreachable.

x may refer to a variety of other objects; some will be the resources needing cleanup, others may be ordinary, non-resource objects.

For proper cleanup, resource objects **_already_** must remain reachable longer than x (so their cleanup can be performed even after x is unreachable). Cleaner takes care of this for you (The Cleaner instance keeps a reference to the registered "cleaning action", which refers to the resources). Or, one must roll their own if using Reference+ReferenceQueue directly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1472163987

From darcy at openjdk.org  Wed Jan 31 00:51:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 Jan 2024 00:51:01 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: <QoS00-jNWBQeQ0UaTKSs6hwnGCnT1zD0GvoS9FNBEac=.23031fd7-1b0c-43b8-bbc5-a6fa02b75661@github.com>
References: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
 <QoS00-jNWBQeQ0UaTKSs6hwnGCnT1zD0GvoS9FNBEac=.23031fd7-1b0c-43b8-bbc5-a6fa02b75661@github.com>
Message-ID: <LPV3Skj6Xkf8gpcZf7bdm5EDI-pTmrd-vuTQAzEyYyM=.27456880-f0e8-4d98-a6a4-d698391a2dec@github.com>

On Tue, 30 Jan 2024 17:21:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Can we maybe see if we can fix these tests without exclusive-accessing them? I find it surprising that `java/lang/StringBuilder` tests are problematic, but `java/lang/StringBuffer` tests are not. Which tests fail?

I agree it would be strongly preferable to allow these tests to run without exclusive access.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1918163496

From bchristi at openjdk.org  Wed Jan 31 00:53:07 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 31 Jan 2024 00:53:07 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v7]
In-Reply-To: <08WIXF8evpw7ZRGFOwA39Xiop2X7epEE0G6_wX3Foo4=.01d3af7d-776b-4c05-9f81-25bbd3b2194d@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <f7xiLmhBedF-ZWjCwx0cDlwLSmZPK76Be-XnTMPN5Ug=.75563fb4-07a4-43e6-a757-f4a7a66479b2@github.com>
 <08WIXF8evpw7ZRGFOwA39Xiop2X7epEE0G6_wX3Foo4=.01d3af7d-776b-4c05-9f81-25bbd3b2194d@github.com>
Message-ID: <ScLdLCYCIG0mCd8sRkZChlOVkzpk7V_V8rXgmIpM1vM=.5854f5d4-cf2a-493a-8be4-a48c5042081f@github.com>

On Mon, 27 Nov 2023 21:51:01 GMT, Hans Boehm <duke at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates to clear() and enqueue()
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 104:
> 
>> 102:  * <ul>
>> 103:  *
>> 104:  * <li> Actions in a thread prior to calling
> 
> Is line 104 needed? Can we just say that Refrence.reachaboilityFence(x) happens-before ...

This language is consistent with other parts of this fix (and elsewhere in the API spec).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1472172567

From bchristi at openjdk.org  Wed Jan 31 01:16:05 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 31 Jan 2024 01:16:05 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v7]
In-Reply-To: <08WIXF8evpw7ZRGFOwA39Xiop2X7epEE0G6_wX3Foo4=.01d3af7d-776b-4c05-9f81-25bbd3b2194d@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <f7xiLmhBedF-ZWjCwx0cDlwLSmZPK76Be-XnTMPN5Ug=.75563fb4-07a4-43e6-a757-f4a7a66479b2@github.com>
 <08WIXF8evpw7ZRGFOwA39Xiop2X7epEE0G6_wX3Foo4=.01d3af7d-776b-4c05-9f81-25bbd3b2194d@github.com>
Message-ID: <i1U3bkHmm7ZpUFqctnGxLPcooUM3zYyjRecIv4gnj3k=.3cbbd757-0efe-43a4-8f94-4dd88f4ef6b6@github.com>

On Mon, 27 Nov 2023 22:52:10 GMT, Hans Boehm <duke at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates to clear() and enqueue()
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 109:
> 
>> 107:  *
>> 108:  * <li>The clearing of a reference by the garbage collector <i>happens-before</i>
>> 109:  * the garbage collector enqueues the reference.</li>
> 
> Is it worth specifying this middle step? Is there a way to tell that something has been enqueued without removing the reference or calling the deprecated (and very dubious) isEnqueued method? Could we just remove this paragraph, and instead start the next one with "The clearing of a reference by the garbage collector ..."

Here, we are building a chain of _happens-befores_ that reaches from RF to dequeue (and on, to the running of the cleaning action, in the case of Cleaner).

A ref can also be cleared by a call to clear(), but that has no memory consistency effects.

So I think it's worth clarifying here that ref-clearing only forms a "link" in the _happens-before_ chain **_when performed by the GC_**.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1472189769

From bpb at openjdk.org  Wed Jan 31 01:22:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jan 2024 01:22:12 GMT
Subject: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding
 zero return value
Message-ID: <DjQUjN6JOxE_eTIAG0h4jk4dsb3iwXja1t0C3cD8qbI=.9e478e8e-8171-4980-a06b-f83b8b8079cb@github.com>

Align the specification of `Unsafe.allocateMemory` with its implementation and with the specification of `Unsafe.reallocateMemory`.

-------------

Commit messages:
 - 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value

Changes: https://git.openjdk.org/jdk/pull/17643/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17643&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324960
  Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17643.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17643/head:pull/17643

PR: https://git.openjdk.org/jdk/pull/17643

From mbalao at openjdk.org  Wed Jan 31 04:18:04 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 31 Jan 2024 04:18:04 GMT
Subject: RFR: 8315487: Security Providers Filter [v7]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <9gWirtGicGY_QrkTssxaig7ITLedj4eoJjffr3CTMOE=.fc6c0cb6-f030-4cfd-bf4f-9b25b7b8d19e@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  ProvidersFilterTest extended to cover all JCA service types.
  
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/f015ba87..b231a75d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=05-06

  Stats: 224 lines in 2 files changed: 200 ins; 1 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

PR: https://git.openjdk.org/jdk/pull/15539

From mdoerr at openjdk.org  Wed Jan 31 06:11:08 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 31 Jan 2024 06:11:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs
In-Reply-To: <crJJowOj-0J1vxYNDxWCZ2OzNbd496wucvDmZxXeNVU=.263c36e1-36ea-4370-9b2e-f3bb90eddafd@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <kkTuRO6ZLza4ZwhWc2qpyuVEfbapG6fUuEw4qzGJBqU=.c08f56ef-f199-4b51-aa1c-fbb6ae79754b@github.com>
 <HSbNrboWAJcLr9zvqUGJjihCorB9McjrG7F_MCaQuFk=.fcb8badd-f89a-4c35-8f5d-43675e46a2a6@github.com>
 <4Pd7oVMUE2HYXJtde1fxURXSaS24X2bK5t2448kwT8s=.8a8c6fbc-3537-4289-8577-a978636f55a2@github.com>
 <vUfeh1jMUQ3c-mkskGp_tsaUGng6iMXg46QDiDwEaWc=.6a5fdc5c-3d3e-466f-9563-486df83e3e7b@github.com>
 <crJJowOj-0J1vxYNDxWCZ2OzNbd496wucvDmZxXeNVU=.263c36e1-36ea-4370-9b2e-f3bb90eddafd@github.com>
Message-ID: <rfQ9NzxEvWiN7Z7WXezmTEVAs4Avy182f2bykzqBwHw=.6ce11f4a-adbc-48ec-a902-50ab5c42beb6@github.com>

On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Yes there is a nice define in the AIX header
>> 
>> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE mechanism. Oh well. 
>> 
>> Anyway, I think this particular can be resolved by not including the standard includes in the header file (which is bad practice anyway!). I'm currently testing this build in our CI to see that it does not break anything else. I'd appreciate if you could take the latest version for a spin, particularly a debug build...
>
>> I'd appreciate if you could take the latest version for a spin, particularly a debug build...
> 
> Yes we pick up the latest version of the PR in a couple of hours for the build+'lots of tests'  (and this includes a fastdebug too).

@MBaesken, @JoKern65: This seems to break the debug build (fast and slow) on AIX:

jdk/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c:101:24: error: no member named 'open64' in 'SpanIteratorFuncs'; did you mean 'open'?
    srData = (*pFuncs->open)(env, si);
                       ^~~~
                       open
/usr/include/fcntl.h:115:14: note: expanded from macro 'open'
#define open    open64
                ^
jdk/src/java.desktop/share/native/libawt/java2d/pipe/SpanIterator.h:37:17: note: 'open' declared here
    void     *(*open)(JNIEnv *env, jobject iterator);
                ^

Ah, that has already been reported above. Yeah, interesting that the normal build has passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918443702

From mbaesken at openjdk.org  Wed Jan 31 08:16:02 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 31 Jan 2024 08:16:02 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: <LPV3Skj6Xkf8gpcZf7bdm5EDI-pTmrd-vuTQAzEyYyM=.27456880-f0e8-4d98-a6a4-d698391a2dec@github.com>
References: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
 <QoS00-jNWBQeQ0UaTKSs6hwnGCnT1zD0GvoS9FNBEac=.23031fd7-1b0c-43b8-bbc5-a6fa02b75661@github.com>
 <LPV3Skj6Xkf8gpcZf7bdm5EDI-pTmrd-vuTQAzEyYyM=.27456880-f0e8-4d98-a6a4-d698391a2dec@github.com>
Message-ID: <uO-n9HkHQPCttBKKNQrsonWPDw1bWX3f5p496i6kRCs=.4a513380-6618-4e8f-ba93-7f5fa4e44974@github.com>

On Wed, 31 Jan 2024 00:48:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Can we maybe see if we can fix these tests without exclusive-accessing them? I find it surprising that `java/lang/StringBuilder` tests are problematic, but `java/lang/StringBuffer` tests are not. Which tests fail?

It is a bit arbitrary which tests fail.
one day :

java/lang/StringBuilder/StringBufferRepeat.java
java/lang/StringBuilder/CompactStringBuilderSerialization.java
java/lang/StringBuilder/Insert.java

other day:
java/lang/StringBuilder/HugeCapacity.java

next day it might differ a bit.
Maybe it would be sufficient to execute only the HugeCapacity test in a non concurrent way because this one seems to be especially resource hungry, but I am not aware how this would work in jtreg (I can only set whole directories).
Currently we run with this patch and the issues are gone.

Is there a way to balance resource usage in jtreg runs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1918595685

From mbaesken at openjdk.org  Wed Jan 31 09:22:07 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 31 Jan 2024 09:22:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
Message-ID: <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>

On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-FOB64
>  - Move #include <stdlib/io.h> out of debug_util.h
>  - Restore AIX dirent64 et al defines
>  - Rollback AIX changes since they are now tracked in JDK-8324834
>  - Remove superfluous setting of FOB64
>  - Replace all foo64() with foo() for large-file functions in the JDK
>  - 8324539: Do not use LFS64 symbols in JDK libs

After adding this additional patch I  fully build fastdebug on AIX (hav to admit it does not look very nice).


diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
index 823475b0a23..ee0109b6806 100644
--- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
+++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
@@ -31,6 +31,10 @@
 #include "SpanIterator.h"
 #include "Trace.h"
 
+#if defined(_AIX) && defined(open)
+#undef open
+#endif
+
 /* The "header" consists of a jint opcode and a jint span count value */
 #define INTS_PER_HEADER  2
 #define BYTES_PER_HEADER 8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918699480

From pminborg at openjdk.org  Wed Jan 31 09:57:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 31 Jan 2024 09:57:05 GMT
Subject: Integrated: 8323601: Improve LayoutPath.PathElement::toString
In-Reply-To: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
Message-ID: <jhMZGHeK07FecJShaOeg0HOKSUGmnUSTLyfNic9HBbo=.1221e233-5d6c-40ac-b6b7-71f7739424dd@github.com>

On Mon, 15 Jan 2024 07:56:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
> 
> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.

This pull request has now been integrated.

Changeset: ec56c72b
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec56c72b5160ea20ed123c6e1e3379b6b13ecb7d
Stats:     58 lines in 3 files changed: 51 ins; 0 del; 7 mod

8323601: Improve LayoutPath.PathElement::toString

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/17417

From abimpoudis at openjdk.org  Wed Jan 31 10:03:23 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 31 Jan 2024 10:03:23 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@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 78 commits:

 - Merge branch 'master' into primitive-patterns
 - Update summary in ExactnessConversionsSupportTest
 - Address review by Jan
 - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
 - Small fix in Javadoc
 - Tidy up Javadoc of Lower.visitTypeTest
 - Tidy up Javadoc of IllegalArgumentException in typeSwitch
 - Improve readability in SwitchBootstraps
 - Update year
 - Cleanup redundant clone
 - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1

-------------

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=56
  Stats: 3818 lines in 45 files changed: 3385 ins; 212 del; 221 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 mcimadamore at openjdk.org  Wed Jan 31 10:16:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 Jan 2024 10:16:06 GMT
Subject: RFR: 8323601: Improve LayoutPath.PathElement::toString [v4]
In-Reply-To: <D_2mDmmrANf1pZylO4ev3sPnLpgcHpBFeQEUANnOSTs=.8f336c74-0964-4b53-b984-a839395f0141@github.com>
References: <PqVAD4DonAXa44Z1udaJhOPDQYC8XboIyrZ0IhqbiXE=.b92ea14a-5acb-4c03-adc2-c90479678312@github.com>
 <D_2mDmmrANf1pZylO4ev3sPnLpgcHpBFeQEUANnOSTs=.8f336c74-0964-4b53-b984-a839395f0141@github.com>
Message-ID: <UJVuM9mq8-Dg9DY2ytahVtNChRQfHXj0dPqH5biAWFw=.f16c6624-0b20-448a-bdc9-d392d7a82227@github.com>

On Tue, 30 Jan 2024 16:58:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add an improved Improve `LayoutPath.PathElement::toString` method simplifying debugging.
>> 
>> Opinions and suggestions for `static PathElement sequenceElement(long start, long step)` are welcome.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework the LayoutPath::toString output

Good job

-------------

PR Review: https://git.openjdk.org/jdk/pull/17417#pullrequestreview-1853361331

From lancea at openjdk.org  Wed Jan 31 11:09:07 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 31 Jan 2024 11:09:07 GMT
Subject: Integrated: 8324632: Update Zlib Data Compression Library to Version
 1.3.1
In-Reply-To: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
References: <jUzS0mddbtstyDMcWENWifBIx1FAaZDKg7BFjCNT9CQ=.a8d4099e-344a-4937-97b4-d9ec56e9d517@github.com>
Message-ID: <gT1gAH-wYDpBsziMGZlNp7G74DXV72niWBQ-dI0OZVM=.f75d16ac-6af9-4990-bbce-55858422429b@github.com>

On Mon, 29 Jan 2024 16:57:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.3 to 1.3.1 in OpenJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib) has released Zlib 1.3.1 on January 24, 2024.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.3.1..v1.3) between 1.3 and 1.3.1
> 
> Mach5 tiers1-3 have run clean

This pull request has now been integrated.

Changeset: b5c267fc
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5c267fc8a0af50be9e3d1d09cdaa6bf4bb29851
Stats:     164 lines in 14 files changed: 82 ins; 35 del; 47 mod

8324632: Update Zlib Data Compression Library to Version 1.3.1

Reviewed-by: iris, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17619

From pminborg at openjdk.org  Wed Jan 31 13:10:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 31 Jan 2024 13:10:09 GMT
Subject: RFR: 8323746: Add PathElement hashCode and equals
Message-ID: <QLAfHIJ8qW8zx70H8hBIbqRMc6b_WT7rRU2pxotZSnM=.151ad092-2318-47bf-bc3b-1fb98e7bb020@github.com>

This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`.

In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. 

It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code.

-------------

Commit messages:
 - Turn some record classes into regular classes
 - Rewrite PathElement implementations using records

Changes: https://git.openjdk.org/jdk/pull/17651/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323746
  Stats: 182 lines in 3 files changed: 106 ins; 31 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/17651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17651/head:pull/17651

PR: https://git.openjdk.org/jdk/pull/17651

From pminborg at openjdk.org  Wed Jan 31 13:17:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 31 Jan 2024 13:17:26 GMT
Subject: RFR: 8325001: Typo in the javadocs for the Arena::ofShared method
Message-ID: <eYIdBY9PhoOa7TkbK1tNPQnn3Erlb4pcMj29li6FDLw=.2acf060f-4488-47b3-83f6-1a550bfdcc20@github.com>

This PR fixes a typo in the documentation for the `Arena::ofShared`.

-------------

Commit messages:
 - Fix typo

Changes: https://git.openjdk.org/jdk/pull/17653/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325001
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17653/head:pull/17653

PR: https://git.openjdk.org/jdk/pull/17653

From eirbjo at openjdk.org  Wed Jan 31 13:19:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 31 Jan 2024 13:19:03 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <XUu4HrzCChqMUMyJ1U_XRxORNKz57lQorRGEX_sAwXg=.b9bc4b8e-63d5-43b3-a90d-5ae8d36d6869@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
 <XUu4HrzCChqMUMyJ1U_XRxORNKz57lQorRGEX_sAwXg=.b9bc4b8e-63d5-43b3-a90d-5ae8d36d6869@github.com>
Message-ID: <-6COjPHn6ZfPsd02Bz2I4rPxnqNlnV3kqk1HrAxuNkQ=.bb336f35-4f22-4b7c-8f20-eb9cc3a83ec7@github.com>

On Wed, 24 Jan 2024 07:08:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Sundar @sundararajana, given your past work on this test, do you have any thoughts on this change?

@jaikiran We have not heard back from @sundararajana in the last week. It would be nice to see this low-risk change integrated. 

I'm sure we can respond to any post-integration feedback with a follow-up PR. Do you agree?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16830#issuecomment-1919084618

From jpai at openjdk.org  Wed Jan 31 14:02:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 14:02:11 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <-6COjPHn6ZfPsd02Bz2I4rPxnqNlnV3kqk1HrAxuNkQ=.bb336f35-4f22-4b7c-8f20-eb9cc3a83ec7@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
 <XUu4HrzCChqMUMyJ1U_XRxORNKz57lQorRGEX_sAwXg=.b9bc4b8e-63d5-43b3-a90d-5ae8d36d6869@github.com>
 <-6COjPHn6ZfPsd02Bz2I4rPxnqNlnV3kqk1HrAxuNkQ=.bb336f35-4f22-4b7c-8f20-eb9cc3a83ec7@github.com>
Message-ID: <0oDs4q9LYuFdoFgoIZ1p9FlI2WDRb4p-YE4frD2auMc=.5b327740-e6d7-42c3-96af-f388a57240ea@github.com>

On Wed, 31 Jan 2024 13:16:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Thank you for the update. This test-only change looks OK to me.
>> 
>> Hello Sundar @sundararajana, given your past work on this test, do you have any thoughts on this change?
>
>> Hello Sundar @sundararajana, given your past work on this test, do you have any thoughts on this change?
> 
> @jaikiran We have not heard back from @sundararajana in the last week. It would be nice to see this low-risk change integrated. 
> 
> I'm sure we can respond to any post-integration feedback with a follow-up PR. Do you agree?

Hello Eirik @eirbjo, please give me a few more hours. I just now noticed that this test resides in tier2, so github actions job doesn't cover it. I'll trigger a CI run and once it's done successfully, you can go ahead and integrate this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16830#issuecomment-1919156493

From jpai at openjdk.org  Wed Jan 31 14:08:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 14:08:07 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <hjFRW1SsEHmHhauDONdK3ZNY9xMzsbxBYGEG32u02aQ=.74fb4fe4-cf72-4e65-9f6c-ac2a9a4da751@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
 <XUu4HrzCChqMUMyJ1U_XRxORNKz57lQorRGEX_sAwXg=.b9bc4b8e-63d5-43b3-a90d-5ae8d36d6869@github.com>
 <-6COjPHn6ZfPsd02Bz2I4rPxnqNlnV3kqk1HrAxuNkQ=.bb336f35-4f22-4b7c-8f20-eb9cc3a83ec7@github.com>
 <hjFRW1SsEHmHhauDONdK3ZNY9xMzsbxBYGEG32u02aQ=.74fb4fe4-cf72-4e65-9f6c-ac2a9a4da751@github.com>
Message-ID: <OB-is0ANksuGxXyuh4fLRu3cagRBMb0XocA_oML6AV0=.fda54968-f3e4-4944-80de-b5d31a5cb3cd@github.com>

On Wed, 31 Jan 2024 14:02:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> 
> Whoops, I just integrated after the approval from @sundararajana, seconds before this comment.

That's alright. 

> 
> What is the best action here, just have a rollback PR ready in case of failures?

Typically when such failures happen, depending on the noise it creates in the CI, the change is either backed out https://openjdk.org/guide/#backing-out-a-change or a JBS issue is created to fix the issue, leaving the original change around. We don't need to do anything for now. I'll keep a watch on the test run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16830#issuecomment-1919170214

From eirbjo at openjdk.org  Wed Jan 31 14:02:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 31 Jan 2024 14:02:12 GMT
Subject: Integrated: 8320712: Rewrite BadFactoryTest in pure Java
In-Reply-To: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
Message-ID: <aDUj04NUgOktBvK6EjRHJV2r3GfsY0o2_JBh4phmz-c=.d8990cff-0e2c-4c98-8fcd-391c0e660f04@github.com>

On Mon, 27 Nov 2023 17:44:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. 
> 
> Reviewers may notice the following changes:
> 
> - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java`
> - The main method has been replaced with a JUnit `@Test` method
> - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959`
> - The `@summary` tag was updated since the existing summary was slightly confusing
> - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager`
> - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see  #16585.
> 
> Verified by running:
> 
> 
> % make test TEST="test/jdk/javax/script/JDK_8196959"
>   [..]
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/javax/script/JDK_8196959               1     1     0     0   
> 
> 
> Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection.

This pull request has now been integrated.

Changeset: 66971600
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66971600f7ba796ff5bb9714591c3faa0bb2249d
Stats:     86 lines in 2 files changed: 24 ins; 60 del; 2 mod

8320712: Rewrite BadFactoryTest in pure Java

Reviewed-by: jpai, sundar

-------------

PR: https://git.openjdk.org/jdk/pull/16830

From sundar at openjdk.org  Wed Jan 31 14:02:10 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 31 Jan 2024 14:02:10 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
Message-ID: <NzVldiL13eSLonoCepGu1NfgFe5DwKL1qLPuUKpuYsU=.d4a527e7-a185-4acf-84d4-217dafd9d398@github.com>

On Wed, 24 Jan 2024 06:50:36 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. 
>> 
>> Reviewers may notice the following changes:
>> 
>> - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java`
>> - The main method has been replaced with a JUnit `@Test` method
>> - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959`
>> - The `@summary` tag was updated since the existing summary was slightly confusing
>> - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager`
>> - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see  #16585.
>> 
>> Verified by running:
>> 
>> 
>> % make test TEST="test/jdk/javax/script/JDK_8196959"
>>   [..]
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/javax/script/JDK_8196959               1     1     0     0   
>> 
>> 
>> Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Remove the @library tag, the META-INF service definition file is already on the classpath
>  - Merge branch 'master' into badfactory-java-rewritte
>  - Add the Java rewrite issue to the @bug list
>  - Merge branch 'master' into badfactory-java-rewritte
>    
>    # Conflicts:
>    #	test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh
>  - Move jtreg tags from before to after imports
>  - Merge branch 'master' into badfactory-java-rewritte
>  - Update the @summary to describe the purpose of the test, not the BadFactory
>  - Add comment describing the initialization of ScriptEngineManager
>  - Implement BadFactoryTest in pure Java

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16830#pullrequestreview-1853796424

From eirbjo at openjdk.org  Wed Jan 31 14:05:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 31 Jan 2024 14:05:08 GMT
Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]
In-Reply-To: <-6COjPHn6ZfPsd02Bz2I4rPxnqNlnV3kqk1HrAxuNkQ=.bb336f35-4f22-4b7c-8f20-eb9cc3a83ec7@github.com>
References: <zmG__NN-1TrNObQ97ZH4rxrBozrCQpc9c6iZc8CCUVM=.c748210e-3772-498a-b683-20568fea8194@github.com>
 <O2SxAg5M05DPTJZ6CL0NL76oJPPYG-MaVxxG2PC8ZM0=.b4355e98-1bfa-4f4a-9ed2-4985f3fe5f6f@github.com>
 <XUu4HrzCChqMUMyJ1U_XRxORNKz57lQorRGEX_sAwXg=.b9bc4b8e-63d5-43b3-a90d-5ae8d36d6869@github.com>
 <-6COjPHn6ZfPsd02Bz2I4rPxnqNlnV3kqk1HrAxuNkQ=.bb336f35-4f22-4b7c-8f20-eb9cc3a83ec7@github.com>
Message-ID: <hjFRW1SsEHmHhauDONdK3ZNY9xMzsbxBYGEG32u02aQ=.74fb4fe4-cf72-4e65-9f6c-ac2a9a4da751@github.com>

On Wed, 31 Jan 2024 13:16:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Thank you for the update. This test-only change looks OK to me.
>> 
>> Hello Sundar @sundararajana, given your past work on this test, do you have any thoughts on this change?
>
>> Hello Sundar @sundararajana, given your past work on this test, do you have any thoughts on this change?
> 
> @jaikiran We have not heard back from @sundararajana in the last week. It would be nice to see this low-risk change integrated. 
> 
> I'm sure we can respond to any post-integration feedback with a follow-up PR. Do you agree?

> Hello Eirik @eirbjo, please give me a few more hours. I just now noticed that this test resides in tier2, so github actions job doesn't cover it. I'll trigger a CI run and once it's done successfully, you can go ahead and integrate this.

Whoops, I just integrated after the approval from @sundararajana, seconds before this comment.

What is the best action here, just have a rollback PR ready in case of failures?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16830#issuecomment-1919164228

From abimpoudis at openjdk.org  Wed Jan 31 14:21:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 31 Jan 2024 14:21:14 GMT
Subject: Integrated: 8303374: Implement JEP 455: Primitive Types in Patterns, 
 instanceof, and switch (Preview)
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <7MBpFjawIZA1YtjJ8_wP_6UeqG7n7wXF6N1yehtb150=.c8531d10-e969-4cac-bd95-d4e8748bfc49@github.com>

On Fri, 8 Sep 2023 14:17:29 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

This pull request has now been integrated.

Changeset: 1733d2ea
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1733d2ea244756238c302d802511eb1557cd46ac
Stats:     3818 lines in 45 files changed: 3385 ins; 212 del; 221 mod

8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Gavin Bierman <gbierman at openjdk.org>
Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Raffaello Giulietti <rgiulietti at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/15638

From jkratochvil at openjdk.org  Wed Jan 31 15:42:32 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 31 Jan 2024 15:42:32 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v6]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <Qz_xMJugy1mvP-8EeNufGZfqjld68aQeS73sdNWiq4E=.a4c1d611-70e6-409c-99ba-180eec099b53@github.com>

> The testcase requires root permissions.

Jan Kratochvil has updated the pull request with a new target base 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 master-cgroup
 - Fail reading memory.stat only once
 - Extend cgroup test
 - Add read_hierarchical_memsw_limit
 - Add cgroup2 hierarchical_memory_limit support, kernel patch not yet submitted
 - Remove unneeded jdk.test.lib.helpers.ClassFileInstaller
 - Fix test/jdk/jdk/internal/platform/cgroup/ testcases regression
 - Fix cgroup1 hierarchical limit reading
 - Fix the testcase for cgroup1
 - NestedCgroup: Better error reporting
 - ... and 5 more: https://git.openjdk.org/jdk/compare/d82f199c...9fe67514

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/0c912965..9fe67514

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=04-05

  Stats: 20562 lines in 1320 files changed: 8514 ins; 1856 del; 10192 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 jkratochvil at openjdk.org  Wed Jan 31 15:42:32 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 31 Jan 2024 15:42:32 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: <QZ94TIavipCvrdj9KK8D549F8MCpsg4tY5p3Rmhmrs8=.39b18198-e69a-466b-9890-57437fe41491@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>
 <QZ94TIavipCvrdj9KK8D549F8MCpsg4tY5p3Rmhmrs8=.39b18198-e69a-466b-9890-57437fe41491@github.com>
Message-ID: <QrU7O80XB7vn93wYbDEYMuycGZ2SUFeRWloL1d_5_eA=.cfe6d60f-8352-44ba-8d0a-aa546a17e987@github.com>

On Fri, 12 Jan 2024 17:12:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Walking the directory hierarchy (**and** interface files) on every call of `physical_memory()` (or `active_processor_count()` for CPU) seems concerning.

I have therefore implemented a hierarchical `memory.stat` extension for cgroup2 which already exists for cgroup1 - if the patch is agreed upon I will submit it to Linux kernel: [cgroup2-hierarchical_memory_limit.patch.txt](https://github.com/openjdk/jdk/files/14113452/cgroup2-hierarchical_memory_limit.patch.txt)

> Since it seems unlikely for cgroup interface file paths changing during runtime, walking the hierarchy for every look-up seems overkill. Note that the prime users of this feature are in-container use, where most runtimes have the limit settings at the leaf.

While I understand the most common change of the limits is at the leaf technically any parent group limit can change. Which is also what this patch is implementing. For the performance issue I have implemented the Linux kernel extension above.

> `N` files per metric to look at where it used to be one file (i.e. constant).

The problem is any of the files can change. But to fix the performance I have implemented the Linux kernel patch above.

> I wonder if it would be sufficient to "lock" into the cgroup path where the lowest  limits are set in the hierarchy and only use the interface files at that path of a specific controller.

That mostly disables the functionality of this patch.


>     * There seems to be an inconsistency between cgroups v1 (no recursive look-up) and cgroups v2  (recursive look-up). Why? I think we should employ the same semantics to both  versions (and drop the hierarchical work-around - [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338) - for cg v1).

I did not much expect anyone still uses cgroup1. Plus customer was also interested in cgroup2. AFAIK a last OS using cgroup1 was RHEL-7 which will have EOL in a few months. But then I tried to implement cgroup1 but there it sort of already worked thanks for your [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338). I just fixed there to prefer the hierarchical limit over the leaf limit (and the testcase does test it now) as that is what is used by Linux kernel.

And then my Linux kernel patch implements the same `memory.stat` way even for cgroup2.

>     * There also seems to be an inconsistency between metrics being iterated. `memory.max` and `memory.swap.max`  and `memory.swap.current` are being iterated, others, like CPU quotas (`cpu.max` or
>       `cpu.weight`) not. Why? Both limits could potentially be one path up the hierarchy, meaning that cpu limits imposed that way wouldn't be detected.

That is a correct comment. Customer asked only for `memory`. I can implement `cpu` but I would like to find out the approved approach first before implementing the same also for `cpu`.

>     * What testing have you done on this? Did this run through cgroups v1 and cgroups v2  testing? I see failures in `jdk/internal/platform/cgroup` tests (compilation fails).

Thanks for the catch, I have fixed the failure now. I rely on GHA (GitHub Actions) as running the testsuite on my local machine takes 24 hours with many fuzzy results so it is very time consuming to reliably test a patch.

> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 287:
> 
>> 285:   _paths_size = 0;
>> 286:   for (const char *cs = _cgroup_path; (cs = strchr(cs, '/')); ++cs)
>> 287:     ++_paths_size;
> 
> What happens if we end up having multiple slashes? Like `/foo//bar/baz`? This logic would be a good candidate for having a gtest.

It should not happen as we get the cgroup directory path from Linux kernel. But I have added a gtest for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1919349149
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1472971602

From naoto at openjdk.org  Wed Jan 31 17:55:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 Jan 2024 17:55:02 GMT
Subject: RFR: JDK-6285888: ChoiceFormat can support unescaped relational
 symbols in the Format segment [v2]
In-Reply-To: <KpSLzTox6u1ecpTC_z8jxHv6OeFYcQcdny_ghXL1V1A=.8b637d59-dd46-49a4-b098-35b6ea564178@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
 <KpSLzTox6u1ecpTC_z8jxHv6OeFYcQcdny_ghXL1V1A=.8b637d59-dd46-49a4-b098-35b6ea564178@github.com>
Message-ID: <zYe4lYy6lbwojsPrqudgtRRGPpO_NsMiNXEibqbUlr0=.27586a8f-4d76-4ba5-a699-2266f9936b1a@github.com>

On Tue, 30 Jan 2024 23:09:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.
>> 
>> Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.
>> 
>> For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.
>> 
>> Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update wording on quoting behavior

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17640#pullrequestreview-1854463383

From pminborg at openjdk.org  Wed Jan 31 18:02:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 31 Jan 2024 18:02:07 GMT
Subject: Integrated: 8323621: JDK build should exclude snippet class in
 java.lang.foreign
In-Reply-To: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
References: <RJ0yhK0lR_VNdQg2VUj1H_F6G5oQ0ZoY_RwsSFQtPic=.94eb1ce3-c162-47b7-ac67-48c1dad7a09f@github.com>
Message-ID: <lRgt8tzJ7BmEt_q11Kw4sPkIqdrIWNUNfMHJ5vztiwo=.e6860b53-5a5e-4655-beea-9e21f590ba27@github.com>

On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build.

This pull request has now been integrated.

Changeset: f2920533
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2920533e97c0e0eef711c1e020a9a5cc610170f
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8323621: JDK build should exclude snippet class in java.lang.foreign

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/17403

From mcimadamore at openjdk.org  Wed Jan 31 18:24:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 Jan 2024 18:24:01 GMT
Subject: RFR: 8323746: Add PathElement hashCode and equals
In-Reply-To: <QLAfHIJ8qW8zx70H8hBIbqRMc6b_WT7rRU2pxotZSnM=.151ad092-2318-47bf-bc3b-1fb98e7bb020@github.com>
References: <QLAfHIJ8qW8zx70H8hBIbqRMc6b_WT7rRU2pxotZSnM=.151ad092-2318-47bf-bc3b-1fb98e7bb020@github.com>
Message-ID: <2zRwcXQMMxxvY08iS2mnnf3zXZFYeiF5L-C4iZWvZeI=.5c54d231-bd7c-41c8-ad94-d45b15cfb2d2@github.com>

On Wed, 31 Jan 2024 13:04:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`.
> 
> In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. 
> 
> It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code.

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 454:

> 452:     }
> 453: 
> 454:     public static final class SequenceElement

Why are these not empty records?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17651#discussion_r1473276715

From dfuchs at openjdk.org  Wed Jan 31 19:40:02 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 31 Jan 2024 19:40:02 GMT
Subject: RFR: 8325001: Typo in the javadocs for the Arena::ofShared method
In-Reply-To: <eYIdBY9PhoOa7TkbK1tNPQnn3Erlb4pcMj29li6FDLw=.2acf060f-4488-47b3-83f6-1a550bfdcc20@github.com>
References: <eYIdBY9PhoOa7TkbK1tNPQnn3Erlb4pcMj29li6FDLw=.2acf060f-4488-47b3-83f6-1a550bfdcc20@github.com>
Message-ID: <Hskt1qfvSmx1oxwRfChUQ0saSi7UMb_5OdjVZLtgF78=.7fe3c099-ff79-475c-9c23-658fa4c944dd@github.com>

On Wed, 31 Jan 2024 13:12:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a typo in the documentation for the `Arena::ofShared`.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17653#pullrequestreview-1854679366

From sviswanathan at openjdk.org  Wed Jan 31 21:57:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 31 Jan 2024 21:57:06 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11]
In-Reply-To: <JOTMzJHXX6Lj9sEMj1-WspqmIcI-5wFkpDSGYISaGTU=.2b23d689-d1e5-4ca6-a9cb-ad32b896ff31@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <JOTMzJHXX6Lj9sEMj1-WspqmIcI-5wFkpDSGYISaGTU=.2b23d689-d1e5-4ca6-a9cb-ad32b896ff31@github.com>
Message-ID: <tl8gx9bpCpk-nD54TA5nNMHvYJEjAg7SmtK26ZThdXs=.911d8f62-5605-4676-af0f-9ed14e16d9d7@github.com>

On Sun, 21 Jan 2024 06:55:43 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.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:
> 
>   Review comments resolutions.

src/hotspot/cpu/x86/assembler_x86.cpp line 3297:

> 3295: }
> 3296: 
> 3297: // Move Unaligned EVEX enabled Vector (programmable : 8,16,32,64)

The  (programmable : 8,16,32,64) part of the comment could be removed. This is not something special here for this instruction. Or at the minimum we should say "programmable vector length".

src/hotspot/cpu/x86/assembler_x86.cpp line 13587:

> 13585: }
> 13586: 
> 13587: void Assembler::bt(Register dst, Register src) {

We could name it btq() as it is a 64 bit instruction.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1574:

> 1572: void C2_MacroAssembler::vpackI2X(BasicType elem_bt, XMMRegister dst,
> 1573:                                  XMMRegister ones, XMMRegister xtmp,
> 1574:                                  int vlen_enc) {

The ones and xtmp argument is not used in vpackI2X?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1603:

> 1601:     bitlevel_offset_shift = 3;
> 1602:     nomlarized_index_shift = 2;
> 1603:   }

It takes a lot of effort to understand the logic here. Good to have a comment here that we are gathering 32 bit aligned elements first and then extracting the required subword from that.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613:

> 1611:   vpand(xtmp, idx_vec, xtmp, vlen_enc);
> 1612:   // Load double words from normalized indices.
> 1613:   evpgatherdd(dst, gmask, Address(base, xtmp, scale), vlen_enc);

Could we not do here directly:
evpgatherdd(dst, gmask, Address(base, idx_vec, scale), vlen_enc);
Then we dont need lines 1609-1611 and also 1616-1621 as well.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613:

> 1611:   vpand(xtmp, idx_vec, xtmp, vlen_enc);
> 1612:   // Load double words from normalized indices.
> 1613:   evpgatherdd(dst, gmask, Address(base, xtmp, scale), vlen_enc);

Another question, looks to me that we could read beyond the allocated memory for the array here. e.g. consider the following case:
* It is a byte gather
* The byte source array is of size 41, i.e. only indices 0-40 are valid
* The gather index is 40

Then as part of evpgatherdd we would be reading bytes at 40-43 offset from source array.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1622:

> 1620:   // 16 bits(for short)/8 bits(for byte) of each double word lane.
> 1621:   vpsrlvd(dst, dst, xtmp, vlen_enc);
> 1622:   // Pack double word vector into short vector.

Pack double word vector into short/byte vector.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473298053
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473305137
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473311064
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473484078
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473486672
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473488519
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473464504

From jlu at openjdk.org  Wed Jan 31 22:28:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 31 Jan 2024 22:28:16 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter
Message-ID: <KgYv_zUO6u33Kh0xsRLkcVtisnwzca5ChZZJxCWWP5w=.e9ef803f-1470-4d62-97e2-b110f8baf846@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.

The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
The `FormatStyles`: compact_short, compact_long, or, and unit are added.

For example, previously,


Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);


would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`

Now, a user can call


MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);


which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/17663/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318761
  Stats: 1166 lines in 6 files changed: 871 ins; 198 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/17663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663

PR: https://git.openjdk.org/jdk/pull/17663

From sviswanathan at openjdk.org  Wed Jan 31 23:56:04 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 31 Jan 2024 23:56:04 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11]
In-Reply-To: <tl8gx9bpCpk-nD54TA5nNMHvYJEjAg7SmtK26ZThdXs=.911d8f62-5605-4676-af0f-9ed14e16d9d7@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <JOTMzJHXX6Lj9sEMj1-WspqmIcI-5wFkpDSGYISaGTU=.2b23d689-d1e5-4ca6-a9cb-ad32b896ff31@github.com>
 <tl8gx9bpCpk-nD54TA5nNMHvYJEjAg7SmtK26ZThdXs=.911d8f62-5605-4676-af0f-9ed14e16d9d7@github.com>
Message-ID: <x5iDjHqTByopA44bdarCa77-zpgk2aZXmKQdPPnXB0s=.306ef0b3-fae8-41ef-84fd-d402486364c7@github.com>

On Wed, 31 Jan 2024 21:31:21 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613:
> 
>> 1611:   vpand(xtmp, idx_vec, xtmp, vlen_enc);
>> 1612:   // Load double words from normalized indices.
>> 1613:   evpgatherdd(dst, gmask, Address(base, xtmp, scale), vlen_enc);
> 
> Another question, looks to me that we could read beyond the allocated memory for the array here. e.g. consider the following case:
> * It is a byte gather
> * The byte source array is of size 41, i.e. only indices 0-40 are valid
> * The gather index is 40
> 
> Then as part of evpgatherdd we would be reading bytes at 40-43 offset from source array.

I guess the fact that the Java objects are 8 byte alignment padded and the alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473627981