Re: RFR: 8333396: Performance regression of DecimalFormat.format [v11]
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself
> contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is
> lock-free.
>
> ### Benchmark testcase
>
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
>
> private DecimalFormat format;
>
> @Setup(Level.Trial)
> public void setup() {
> format = new DecimalFormat("#0.0");
> }
>
> @Benchmark
> public void testNewAndFormat() throws InterruptedException {
> new DecimalFormat("#0.0").format(9524234.1236457);
> }
>
> @Benchmark
> public void testNewOnly() throws InterruptedException {
> new DecimalFormat("#0.0");
> }
>
> @Benchmark
> public void testFormatOnly() throws InterruptedException {
> format.format(9524234.1236457);
> }
> }
>
>
> ### Test result
> Current JDK before optimize
>
> Benchmark Mode CntScore Error Units
> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op
> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op
> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op
>
>
>
> Current JDK after optimize
>
> Benchmark Mode CntScore Error Units
> JmhDecimalFormat.testFormatOnlyavgt 50 351.499 ? 0.761 ns/op
> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op
> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op
>
>
> ### JDK 11
>
> Benchmark Mode CntScore Error Units
> JmhDecimalFormat.testFormatOnlyavgt 50 364.214 ? 1.191 ns/op
> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op
> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op
lingjun-cg has updated the pull request incrementally with one additional
commit since the last revision:
896: Performance regression of DecimalFormat.format
-
Changes:
- all: https://git.openjdk.org/jdk/pull/19513/files
- new: https://git.openjdk.org/jdk/pull/19513/files/67c724c7..b6646c5d
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk=19513=10
- incr: https://webrevs.openjdk.org/?repo=jdk=19513=09-10
Stats: 305 lines in 6 files changed: 158 ins; 122 del; 25 mod
Patch: https://git.openjdk.org/jdk/pull/19513.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513
PR: https://git.openjdk.org/jdk/pull/19513
Re: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
On Mon, 24 Jun 2024 17:00:57 GMT, Naoto Sato wrote: >> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed >> LocaleProvidersRun and CalendarDataRegression, and >> [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. >> I'm guessing it's a mistake in resolving merge conflict. > > Thanks for spotting that out. It does seem to be a merge error. Thanks for the review. @naotoj Do you mind sponsoring the change? - PR Comment: https://git.openjdk.org/jdk/pull/19849#issuecomment-2187920188
[jdk23] Integrated: 8222884: ConcurrentClassDescLookup.java times out intermittently
On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of > [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit > [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jaikiran Pai on 12 Jun 2024 and > was reviewed by Roger Riggs and Matthias Baesken. > > Thanks! This pull request has now been integrated. Changeset: 08c7c383 Author:Christoph Langer URL: https://git.openjdk.org/jdk/commit/08c7c38342809c60f5fdea70717362a72b00f6e9 Stats: 36 lines in 1 file changed: 7 ins; 7 del; 22 mod 8222884: ConcurrentClassDescLookup.java times out intermittently Reviewed-by: mdoerr Backport-of: bd046d9b9e79e4eea89c72af358961ef6e98e660 - PR: https://git.openjdk.org/jdk/pull/19853
Re: RFR: 8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal [v13]
On Mon, 17 Jun 2024 04:58:41 GMT, Shaojin Wen wrote:
>> The current versions of FloatToDecimal and DoubleToDecimal allocate
>> additional objects. Reducing these allocations can improve the performance
>> of Float/Double.toString and AbstractStringBuilder's append(float/double).
>>
>> This patch is just a code refactoring to reduce object allocation, but does
>> not change the Float/Double to decimal algorithm.
>>
>> The following code comments the allocated objects to be removed.
>>
>>
>> class FloatToDecimal {
>> public static String toString(float v) {
>> // allocate object FloatToDecimal
>> return new FloatToDecimal().toDecimalString(v);
>> }
>>
>> public static Appendable appendTo(float v, Appendable app)
>> throws IOException {
>> // allocate object FloatToDecimal
>> return new FloatToDecimal().appendDecimalTo(v, app);
>> }
>>
>> private Appendable appendDecimalTo(float v, Appendable app)
>> throws IOException {
>> switch (toDecimal(v)) {
>> case NON_SPECIAL:
>> // allocate object char[]
>> char[] chars = new char[index + 1];
>> for (int i = 0; i < chars.length; ++i) {
>> chars[i] = (char) bytes[i];
>> }
>> if (app instanceof StringBuilder builder) {
>> return builder.append(chars);
>> }
>> if (app instanceof StringBuffer buffer) {
>> return buffer.append(chars);
>> }
>> for (char c : chars) {
>> app.append(c);
>> }
>> return app;
>> // ...
>> }
>> }
>> }
>>
>> class DoubleToDecimal {
>> public static String toString(double v) {
>> // allocate object DoubleToDecimal
>> return new DoubleToDecimal(false).toDecimalString(v);
>> }
>>
>> public static Appendable appendTo(double v, Appendable app)
>> throws IOException {
>> // allocate object DoubleToDecimal
>> return new DoubleToDecimal(false).appendDecimalTo(v, app);
>> }
>>
>> private Appendable appendDecimalTo(double v, Appendable app)
>> throws IOException {
>> switch (toDecimal(v, null)) {
>> case NON_SPECIAL:
>> // allocate object char[]
>> char[] chars = new char[index + 1];
>> for (int i = 0; i < chars.length; ++i) {
>> chars[i] = (char) bytes[i];
>> }
>> ...
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Utf16 case remove `append first utf16 char`
I would request a review from @rgiulietti, author of the original code.
src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 154:
> 152: int length = s.length();
> 153: if (coder == LATIN1) {
> 154: for (int i = 0; i < length; ++i) {
Can we use `s.getBytes(0, length, str, index)` and add
`@SuppressWarnings("deprecation")` for performance?
-
PR Review: https://git.openjdk.org/jdk/pull/19730#pullrequestreview-2137225522
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1651921455
Re: RFR: 8333396: Performance regression of DecimalFormat.format [v10]
On Fri, 21 Jun 2024 07:25:27 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself
>> contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is
>> lock-free.
>>
>> ### Benchmark testcase
>>
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>>
>> private DecimalFormat format;
>>
>> @Setup(Level.Trial)
>> public void setup() {
>> format = new DecimalFormat("#0.0");
>> }
>>
>> @Benchmark
>> public void testNewAndFormat() throws InterruptedException {
>> new DecimalFormat("#0.0").format(9524234.1236457);
>> }
>>
>> @Benchmark
>> public void testNewOnly() throws InterruptedException {
>> new DecimalFormat("#0.0");
>> }
>>
>> @Benchmark
>> public void testFormatOnly() throws InterruptedException {
>> format.format(9524234.1236457);
>> }
>> }
>>
>>
>> ### Test result
>> Current JDK before optimize
>>
>> Benchmark Mode CntScore Error Units
>> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op
>> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op
>> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op
>>
>>
>>
>> Current JDK after optimize
>>
>> Benchmark Mode CntScore Error Units
>> JmhDecimalFormat.testFormatOnlyavgt 50 351.499 ? 0.761 ns/op
>> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op
>> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op
>>
>>
>> ### JDK 11
>>
>> Benchmark Mode CntScore Error Units
>> JmhDecimalFormat.testFormatOnlyavgt 50 364.214 ? 1.191 ns/op
>> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op
>> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 896: Performance regression of DecimalFormat.format
src/java.base/share/classes/java/text/Format.java line 456:
> 454: }
> 455:
> 456: final class StringBufferImpl implements StringBuf {
Please don't nest this in an interface; anything nested in an interface is
public, so is the generated nested class, which can be publicly accessed via
reflection or MethodHandle.Lookup.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1651915645
Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
On Thu, 20 Jun 2024 18:58:27 GMT, Naoto Sato wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > I did not mean to introduce a public API for this change (if we do, the fix > cannot be backported). I thought we could define a package private one, but > based on your observation, it may get messier... So I agree that falling back > to `StringBuf` is the way to go, IMO. So, considering all the information given, is it enough to start our new review process? @naotoj @liach @justin-curtis-lu - PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2187842086
Re: RFR: 8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal [v8]
On Sun, 16 Jun 2024 21:25:42 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> code format > > Just suggesting some improvements All suggestions have been fixed, can this PR be integrated? @cl4es @liach - PR Comment: https://git.openjdk.org/jdk/pull/19730#issuecomment-2187784845
Re: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960
On Mon, 24 Jun 2024 22:11:55 GMT, Richard Reingruber wrote: >> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code >> generation and unfortunately it causes StackOverflow on BigEndian platforms. >> >> This patch converts all lambdas in ClassSpecializer into anonymous inner >> classes. >> >> Please review and test on a BigEndian platform. >> >> Thanks, >> Adam > > Hi Adam, > > I've tested this change on a Linux PPC64 big endian system. Sadly I still get > StackOverflowErrors. > I've run only test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java. > I've experimented with `ThreadStackSize` and `VMThreadStackSize` without > success. > > When running the test standalone I get the following message: > > > ./jdk/bin/java > -cp > testclasses:jtreg_latest/lib/testng-7.3.0.jar:jtreg_latest/lib/jcommander-1.82.jar > -XX:+UnlockDiagnosticVMOptions > -XX:UseBootstrapCallInfo=3 > -Xint > org.testng.TestNG > -testclass > ConstantBootstrapsTest > Error occurred during initialization of boot layer > java.lang.StackOverflowError > > > It's likely not a byte ordering problem since @offamitkumar cannot reproduce > the failures on s390x. @reinrich Could you try running with `-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames` and share the full stacktrace again? - PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2187588334
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v11]
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, > even for small numbers. To get an idea of how much the Newton's Method is > slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which > I compare Newton's Method with a version of classical square root algorithm > that I implemented. After implementing Zimmermann's algorithm, it turns out > that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code optimization - Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/d3270015..f895b63b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19710=10 - incr: https://webrevs.openjdk.org/?repo=jdk=19710=09-10 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
Re: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote: > After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code > generation and unfortunately it causes StackOverflow on BigEndian platforms. > > This patch converts all lambdas in ClassSpecializer into anonymous inner > classes. > > Please review and test on a BigEndian platform. > > Thanks, > Adam Hi Adam, I've tested this change on a Linux PPC64 big endian system. Sadly I still get StackOverflowErrors. I've run only test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java. I've experimented with `ThreadStackSize` and `VMThreadStackSize` without success. When running the test standalone I get the following message: ./jdk/bin/java -cp testclasses:jtreg_latest/lib/testng-7.3.0.jar:jtreg_latest/lib/jcommander-1.82.jar -XX:+UnlockDiagnosticVMOptions -XX:UseBootstrapCallInfo=3 -Xint org.testng.TestNG -testclass ConstantBootstrapsTest Error occurred during initialization of boot layer java.lang.StackOverflowError It's likely not a byte ordering problem since @offamitkumar cannot reproduce the failures on s390x. - PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2187498690
Re: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> Thanks!
>
> This is similar with previous JDK-8334396.
> Added some tests.
>
> ### Test
>
> | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
> | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
> | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
> | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
> | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
> | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
>
>
test/micro/org/openjdk/bench/java/lang/Characters.java line 69:
> 67:
> 68: @Benchmark
> 69: public void reverseBytes() {
I'm not sure we want to be adding that benchmark to this class. Could you move
to a different class that will test exclusively `reverseBytes` on `char[]`? You
can then move the code from
`test/micro/org/openjdk/bench/java/lang/Shorts.java` into that same class or a
similarly named class for `short[]`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19830#discussion_r1651605527
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v10]
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, > even for small numbers. To get an idea of how much the Newton's Method is > slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which > I compare Newton's Method with a version of classical square root algorithm > that I implemented. After implementing Zimmermann's algorithm, it turns out > that it is faster than my algorithm even for small numbers. 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 39 additional commits since the last revision: - Merge branch 'openjdk:master' into patchSqrt - Removed useless instruction - Code optimization - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt - Merge branch 'openjdk:master' into patchSqrt - Added JMH benchmark class for Square Root - Normalize blocks - Removed unused import - Simplification of code - Special cases and base case optimization - ... and 29 more: https://git.openjdk.org/jdk/compare/651eb76a...d3270015 - Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/073c6046..d3270015 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19710=09 - incr: https://webrevs.openjdk.org/?repo=jdk=19710=08-09 Stats: 729 lines in 41 files changed: 494 ins; 132 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
Re: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote: > After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code > generation and unfortunately it causes StackOverflow on BigEndian platforms. > > This patch converts all lambdas in ClassSpecializer into anonymous inner > classes. > > Please review and test on a BigEndian platform. > > Thanks, > Adam Marked as reviewed by redestad (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19863#pullrequestreview-2136378062
Re: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin wrote: > [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed > LocaleProvidersRun and CalendarDataRegression, and > [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. > I'm guessing it's a mistake in resolving merge conflict. Marked as reviewed by jlu (Committer). - PR Review: https://git.openjdk.org/jdk/pull/19849#pullrequestreview-2136371650
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v9]
On Sun, 23 Jun 2024 19:03:38 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in >> works [here](https://inria.hal.science/inria-00072854/en/) and >> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's >> Method, even for small numbers. To get an idea of how much the Newton's >> Method is slow, consult my article >> [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method >> with a version of classical square root algorithm that I implemented. After >> implementing Zimmermann's algorithm, it turns out that it is faster than my >> algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision: > > Code optimization Thanks. That's a very nice performance improvement, on my Windows machine the `testHuge...` test is about 2-3x faster, and the other 2 are slightly faster too. This needs a proper review for correctness, which might take a while. - PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2187034545
Re: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin wrote: > [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed > LocaleProvidersRun and CalendarDataRegression, and > [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. > I'm guessing it's a mistake in resolving merge conflict. Thanks for spotting that out. It does seem to be a merge error. - Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19849#pullrequestreview-2136332923
RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137
Hi all, After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. Only change the testcase, the change has been verified, no risk. - Commit messages: - 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 Changes: https://git.openjdk.org/jdk/pull/19864/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19864=00 Issue: https://bugs.openjdk.org/browse/JDK-8334771 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19864/head:pull/19864 PR: https://git.openjdk.org/jdk/pull/19864
RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960
After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms. This patch converts all lambdas in ClassSpecializer into anonymous inner classes. Please review and test on a BigEndian platform. Thanks, Adam - Commit messages: - 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960 Changes: https://git.openjdk.org/jdk/pull/19863/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19863=00 Issue: https://bugs.openjdk.org/browse/JDK-8334872 Stats: 239 lines in 1 file changed: 65 ins; 45 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/19863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19863/head:pull/19863 PR: https://git.openjdk.org/jdk/pull/19863
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v33]
> 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.jmodjava.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.jmodjava.prefs.jmod java.transaction.xa.jmod > jdk.dynalink.jmod jdk.internal.vm.ci.jmod > jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod > java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod > jdk.editpad.jmod jdk.internal.vm.compiler.jmod > jdk.jfr.jmod jdk.management.jmodjdk.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 137 commits: - JLinkDedupTestBatchSizeOne.java test fix Run only the packaged modules version if we have a linkable JDK runtime with packaged modules available as well in the JDK install. - Enable IncludeLocalesPluginTest - Enable GenerateJLIClassesPluginTest.java test - Enable JLinkReproducibleTest.java for linkable JDK images - Remove restriction on directory based modules Enable the following tests: - JLink100Modules.java - JLinkDedupTestBatchSizeOne.java - Comment fix in JRTArchive. Long line in JlinkTask - Comment fixes in ImageFileCreator - Comments and clean-up in JlinkTask - Helper support for linkable JDK runtimes - Test clean-up. class-file API module. - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8 - Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14787=32 Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 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
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find >> code that accesses native functionality. Currently this includes `native` >> method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through >> `--class-path` and `--module-path`, and a set of root modules through >> `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` >> methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module >> names of modules doing native access in a comma separated list. For class >> path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, >> and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > de-dupe on path, not module name Fixed a small bug: https://github.com/openjdk/jdk/pull/19774/commits/40ca91ed47be7697cb720c1b1155d5192e262cc3 I think there's potentially more cleanup that can be done. `ClassResolver` is trying to do too many things atm, I think. It can both iterate over all classes, and do lookups of individual classes, but we only either use one or the other, either to find all classes to scan, or to lookup system classes (the system resolver doesn't even support iterating). I think `ClassResolver` would be better off if it just supported lookups, and then `NativeMethodFinder` operated on individual `ClassModules` instead of iterating over all classes. The iteration can be lifted into `JNativeScanTask::run`, and this spreads out the nesting a bit as well so code doesn't become too hard to follow. I sketched out that idea, and it looks better to me, but there's quite a lot of code motion, without any functional difference ([commit]), so I'll leave it for a followup (unless people want it in this PR). [commit]: https://github.com/JornVernee/jdk/compare/jnativescan...JornVernee:jdk:jnativescan_Refactor - PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2186538931
[jdk23] Integrated: 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS
On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang wrote: > Please review this clean backport of #19708, to make javap recover and > continue after encountering undefined access flag bits set while still > exiting with a code of error, allowing it to error against improper bits > while still providing as much output as possible. This pull request has now been integrated. Changeset: a124e6e5 Author:Chen Liang URL: https://git.openjdk.org/jdk/commit/a124e6e5c7ae7493edd6fe95dde7b21d13af1c8b Stats: 228 lines in 4 files changed: 168 ins; 44 del; 16 mod 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS Reviewed-by: asotona Backport-of: 7e55ed3b106ed08956d2d38b7c99fb81704667c9 - PR: https://git.openjdk.org/jdk/pull/19839
Re: RFR: 8334287: Man page update for jstatd deprecation
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote: > Man page update for JDK-8327793 which marked jstatd as deprecated for removal > in JDK 24. I assume we should hold off reviewing until the warning and the experiment note are combined. - PR Comment: https://git.openjdk.org/jdk/pull/19829#issuecomment-2186517543
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find > code that accesses native functionality. Currently this includes `native` > method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through > `--class-path` and `--module-path`, and a set of root modules through > `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, > and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names > of modules doing native access in a comma separated list. For class path > code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, > and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: de-dupe on path, not module name - Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/a046f6fe..40ca91ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19774=08 - incr: https://webrevs.openjdk.org/?repo=jdk=19774=07-08 Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774
Re: [jdk23] RFR: 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS
On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang wrote: > Please review this clean backport of #19708, to make javap recover and > continue after encountering undefined access flag bits set while still > exiting with a code of error, allowing it to error against improper bits > while still providing as much output as possible. Marked as reviewed by asotona (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19839#pullrequestreview-2135714317
Re: [jdk23] RFR: 8222884: ConcurrentClassDescLookup.java times out intermittently
On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of > [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit > [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jaikiran Pai on 12 Jun 2024 and > was reviewed by Roger Riggs and Matthias Baesken. > > Thanks! LGTM. - Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19853#pullrequestreview-2135601316
Re: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and > was reviewed by Naoto Sato. > > Thanks! Thansk for the sponsor. - PR Comment: https://git.openjdk.org/jdk/pull/19847#issuecomment-2186097277
[jdk23] Integrated: 8333358: java/io/IO/IO.java test fails intermittently
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and > was reviewed by Naoto Sato. > > Thanks! This pull request has now been integrated. Changeset: bd66b6b6 Author:SendaoYan Committer: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/bd66b6b6f9bb0b415b686f06231ccd85dab459da Stats: 69 lines in 3 files changed: 63 ins; 2 del; 4 mod 858: java/io/IO/IO.java test fails intermittently Reviewed-by: prappo Backport-of: 1b1dba8082969244effa86ac03c6053b3b0ddc43 - PR: https://git.openjdk.org/jdk/pull/19847
Re: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and > was reviewed by Naoto Sato. > > Thanks! Thanks for the review. - PR Comment: https://git.openjdk.org/jdk/pull/19847#issuecomment-2186073017
[jdk23] RFR: 8222884: ConcurrentClassDescLookup.java times out intermittently
Hi all, This pull request contains a backport of [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jaikiran Pai on 12 Jun 2024 and was reviewed by Roger Riggs and Matthias Baesken. Thanks! - Commit messages: - Backport bd046d9b9e79e4eea89c72af358961ef6e98e660 Changes: https://git.openjdk.org/jdk/pull/19853/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19853=00 Issue: https://bugs.openjdk.org/browse/JDK-8222884 Stats: 36 lines in 1 file changed: 7 ins; 7 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/19853.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19853/head:pull/19853 PR: https://git.openjdk.org/jdk/pull/19853
Re: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and > was reviewed by Naoto Sato. > > Thanks! Marked as reviewed by prappo (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19847#pullrequestreview-2135235884
Re: [jdk23] RFR: 8334708: FFM: two javadoc problems
On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule wrote: > Hi all, > > This pull request contains a backport of commit > [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Hannes Greule on 22 Jun 2024 and > was reviewed by Maurizio Cimadamore. > > Thanks! Thanks! - PR Comment: https://git.openjdk.org/jdk/pull/19846#issuecomment-2186031401
Re: RFR: 8334734: Remove specialized readXxxEntry methods from ClassReader
On Fri, 21 Jun 2024 15:52:44 GMT, Chen Liang wrote: > `ClassReader.readXxxEntry` were added before we had generic, type-aware > `readEntry` and `readEntryOrNull` APIs (#19330). We should remove these > specialized versions in favor of the generic version to reduce API bloating. Looks good to me, thanks. - Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19833#pullrequestreview-2134895664
[jdk23] Integrated: 8334708: FFM: two javadoc problems
On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule wrote: > Hi all, > > This pull request contains a backport of commit > [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Hannes Greule on 22 Jun 2024 and > was reviewed by Maurizio Cimadamore. > > Thanks! This pull request has now been integrated. Changeset: 3edf379b Author:Hannes Greule Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/3edf379b671c1d8d5a29870ec33fddd7133cf00d Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8334708: FFM: two javadoc problems Reviewed-by: jpai Backport-of: 72ca7bafcd49a98c1fe09da72e4e47683f052e9d - PR: https://git.openjdk.org/jdk/pull/19846
Re: [jdk23] RFR: 8334708: FFM: two javadoc problems
On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule wrote: > Hi all, > > This pull request contains a backport of commit > [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Hannes Greule on 22 Jun 2024 and > was reviewed by Maurizio Cimadamore. > > Thanks! Thank you for your review. - PR Comment: https://git.openjdk.org/jdk/pull/19846#issuecomment-2185687899
