Integrated: 8300863: Remove C-style array declarations in java.io
On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg wrote: > Some variables are declared using old-style declarations. These should be > modified to conform to modern style. > > This is a task derived from https://github.com/openjdk/jdk/pull/11848 This pull request has now been integrated. Changeset: 57f2d48e Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/57f2d48e1e11eb2f87be7e47ab943031696e51f5 Stats: 20 lines in 8 files changed: 1 ins; 1 del; 18 mod 8300863: Remove C-style array declarations in java.io Reviewed-by: alanb, rriggs, darcy, iris - PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: 8290918: Initial nroff manpage generation for JDK 21
On Tue, 24 Jan 2023 05:54:44 GMT, Joe Darcy wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by >> JDK-8300591 >> >> Thanks. > > Marked as reviewed by darcy (Reviewer). Thanks for the review @jddarcy ! I think that suffices for this trivial change. - PR: https://git.openjdk.org/jdk/pull/12154
Integrated: 8290918: Initial nroff manpage generation for JDK 21
On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by > JDK-8300591 > > Thanks. This pull request has now been integrated. Changeset: 6dd8723f Author:David Holmes URL: https://git.openjdk.org/jdk/commit/6dd8723f66a22e626d98c74cff0b0b344a62626d Stats: 28 lines in 27 files changed: 0 ins; 0 del; 28 mod 8290918: Initial nroff manpage generation for JDK 21 Reviewed-by: lancea, iris, darcy - PR: https://git.openjdk.org/jdk/pull/12154
Re: RFR: 8290918: Initial nroff manpage generation for JDK 21
On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by > JDK-8300591 > > Thanks. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12154
Re: RFR: 8290918: Initial nroff manpage generation for JDK 21
On Tue, 24 Jan 2023 01:28:53 GMT, Iris Clark wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by >> JDK-8300591 >> >> Thanks. > > Marked as reviewed by iris (Reviewer). Thanks for the review @irisclark ! - PR: https://git.openjdk.org/jdk/pull/12154
Integrated: 8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat
On Thu, 19 Jan 2023 22:25:51 GMT, Justin Lu wrote: > This PR implements _JEP 413: Code Snippets in Java API Documentation_ for > [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) > and > [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html). > > Code examples using ... blocks are replaced with the @ snippet > syntax where applicable. > > Additionally, for > [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) > internal plain text links using ... are replaced with @ linkplain. > (External links are kept the same) This pull request has now been integrated. Changeset: b3822f50 Author:Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/b3822f50c85524a00a045aa3a3d902f190e35906 Stats: 15 lines in 2 files changed: 0 ins; 2 del; 13 mod 8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat Reviewed-by: lancea, naoto, iris - PR: https://git.openjdk.org/jdk/pull/12108
Integrated: 8300706: Use @snippet in java.text
On Fri, 20 Jan 2023 17:41:35 GMT, Justin Lu wrote: > Some classes / interfaces in java.text have already implemented JEP 413. > > This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the > rest of > [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) > including: > - BreakIterator > - CharacterIterator > - DateFormatSymbols > - DecimalFormat > - NumberFormat > > Code examples using ... blocks are replaced with the @ snippet > syntax where applicable. This pull request has now been integrated. Changeset: 0323609f Author:Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/0323609f44e68ba8d992419a23be7066838a0e01 Stats: 69 lines in 5 files changed: 7 ins; 11 del; 51 mod 8300706: Use @snippet in java.text Reviewed-by: naoto - PR: https://git.openjdk.org/jdk/pull/12121
Re: RFR: 8290918: Initial nroff manpage generation for JDK 21
On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by > JDK-8300591 > > Thanks. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12154
Re: RFR: 8290918: Initial nroff manpage generation for JDK 21
On Mon, 23 Jan 2023 23:24:06 GMT, Lance Andersen wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by >> JDK-8300591 >> >> Thanks. > > Marked as reviewed by lancea (Reviewer). Thanks for the review @LanceAndersen - PR: https://git.openjdk.org/jdk/pull/12154
Re: RFR: 8290918: Initial nroff manpage generation for JDK 21
On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by > JDK-8300591 > > Thanks. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12154
RFR: 8290918: Initial nroff manpage generation for JDK 21
Please review this simple update to the manpage to set the version to 21-ea. This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 Thanks. - Commit messages: - 8290918: Initial nroff manpage generation for JDK 21 Changes: https://git.openjdk.org/jdk/pull/12154/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12154=00 Issue: https://bugs.openjdk.org/browse/JDK-8290918 Stats: 28 lines in 27 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/12154.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12154/head:pull/12154 PR: https://git.openjdk.org/jdk/pull/12154
Re: RFR: JDK-8262994: Refactor String.split to help method inlining [v2]
On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer wrote:
>> The method `String.split` contains a fast-path when the regular expression
>> parameter is not really a regular expression, but just a single split
>> character.
>> This fast path vs. slow path check can be constant folded when the regular
>> expression parameter is a literal constant - a quite frequent pattern (for
>> example, all JDK usages of `String.split` have a constant expression
>> parameter). But method inlining in JIT and AOT compilers can usually not
>> inline `String.split` because the method body is too large. Factoring out
>> the actual fast-path splitting logic into a separate method solves this
>> problem: the JIT or AOT compiler can inline `String.split`, constant-fold
>> the fast/slow path check, and then only the invoke of either the fast path
>> or the slow path remains.
>
> Christian Wimmer has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add comment about method inlining
Looks good.
src/java.base/share/classes/java/lang/String.java line 3130:
> 3128: ((ch-'A')|('Z'-ch)) < 0)) &&
> 3129: (ch < Character.MIN_HIGH_SURROGATE ||
> 3130: ch > Character.MAX_LOW_SURROGATE))
Not your change, but I'd replace them with `MIN_SURROGATE` and `MAX_SURROGATE`
respectively, for readability, taking the opportunity.
-
PR: https://git.openjdk.org/jdk/pull/11791
Re: RFR: JDK-8295859: Update Manual Test Groups [v5]
> This task is created to update the manual test groups. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Added missing manual tests from :jdk_core. - Changes: - all: https://git.openjdk.org/jdk/pull/10864/files - new: https://git.openjdk.org/jdk/pull/10864/files/bd2b50a4..82974f1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=10864=04 - incr: https://webrevs.openjdk.org/?repo=jdk=10864=03-04 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10864.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864 PR: https://git.openjdk.org/jdk/pull/10864
Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v3]
> Added code for Base64 acceleration (encode and decode) which will accelerate > ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3 4309.439 ± 2.632 > ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3 24211.397 ± 102.026 > ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode > Cnt ScoreError Units > Base64Decode.testBase64Decode 144 4 1024 thrpt >3 3961.768 ± 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode > Cnt ScoreError Units > Base64Decode.testBase64Decode 144 4 1024 thrpt >3 14738.051 ± 24.383 ops/ms Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Address review comment - Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/0f4b9c88..c776d90f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12126=02 - incr: https://webrevs.openjdk.org/?repo=jdk=12126=01-02 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126
Re: RFR: JDK-8262994: Refactor String.split to help method inlining [v2]
On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer wrote: >> The method `String.split` contains a fast-path when the regular expression >> parameter is not really a regular expression, but just a single split >> character. >> This fast path vs. slow path check can be constant folded when the regular >> expression parameter is a literal constant - a quite frequent pattern (for >> example, all JDK usages of `String.split` have a constant expression >> parameter). But method inlining in JIT and AOT compilers can usually not >> inline `String.split` because the method body is too large. Factoring out >> the actual fast-path splitting logic into a separate method solves this >> problem: the JIT or AOT compiler can inline `String.split`, constant-fold >> the fast/slow path check, and then only the invoke of either the fast path >> or the slow path remains. > > Christian Wimmer has updated the pull request incrementally with one > additional commit since the last revision: > > Add comment about method inlining Hi Christian, I think this looks good. Reviewed. Regards, Peter - Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.org/jdk/pull/11791
Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v2]
> Added code for Base64 acceleration (encode and decode) which will accelerate > ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3 4309.439 ± 2.632 > ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3 24211.397 ± 102.026 > ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode > Cnt ScoreError Units > Base64Decode.testBase64Decode 144 4 1024 thrpt >3 3961.768 ± 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode > Cnt ScoreError Units > Base64Decode.testBase64Decode 144 4 1024 thrpt >3 14738.051 ± 24.383 ops/ms Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'openjdk:master' into Base64-AVX2 - Remove whitespace - Fix wrong register usage - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Intermediate AVX2 for decode - Fix various AVX support function invocations to get Base64 generated for AVX2 - Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/9cfa6bbd..0f4b9c88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12126=01 - incr: https://webrevs.openjdk.org/?repo=jdk=12126=00-01 Stats: 4398 lines in 281 files changed: 2042 ins; 692 del; 1664 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126
Integrated: Merge jdk20
On Mon, 23 Jan 2023 19:52:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: 56dc3b08 Author:Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/56dc3b08a62f651835c5bccca987d93ba2bb8961 Stats: 28 lines in 27 files changed: 1 ins; 0 del; 27 mod Merge - PR: https://git.openjdk.org/jdk/pull/12150
Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
On Mon, 23 Jan 2023 18:14:16 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661:
>>
>>> 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit);
>>> 2660: __ vmovdqu(xmm11, Address(r13, 0x28));
>>> 2661: __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit);
>>
>> Sorry in advance since I'm probably reading this wrong: the data that `r13`
>> is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does
>> this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up
>> their respective registers with the exact same bits? If so, and since
>> neither of them is mutated in the code below, then perhaps this can be
>> simplified a bit.
>
> You're reading it correctly - this is redundant and could be handled
> differently, as the same value is being loaded into ymm4 and ymm10. I don't
> think there will be any significant performance gain either way. This was
> done in this manner to allow easier transition to URL acceleration when it is
> implemented, as URLs require handling '-' and '_' instead of '+' and '/' ('/'
> = 0x2f).
I was mainly curious if there was some obscure detail or difference that eluded
me. It wouldn't be the first time!
As it's outside of the loop you're probably right about it not being very
important to overall performance, though we should be mindful of setup
overheads of transitioning into AVX code. Especially since inputs likely are
skewed towards the smallest applicable lengths. I think it would be prudent to
run and check the microbenchmark with values near the AVX2 threshold, such as
`maxNumBytes = 48`.
If you choose to keep the code as-is would you mind documenting the rationale
behind the redundancy? (Is there WIP on more generalized URL acceleration that
could be referenced?)
-
PR: https://git.openjdk.org/jdk/pull/12126
RFR: Merge jdk20
Forwardport JDK 20 -> JDK 21 - Commit messages: - Merge - 8290919: Update nroff pages in JDK 20 before RC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk=12150=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk=12150=00.1 Changes: https://git.openjdk.org/jdk/pull/12150/files Stats: 28 lines in 27 files changed: 1 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/12150.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12150/head:pull/12150 PR: https://git.openjdk.org/jdk/pull/12150
Re: RFR: 8300863: Remove C-style array declarations in java.io
On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg wrote: > Some variables are declared using old-style declarations. These should be > modified to conform to modern style. > > This is a task derived from https://github.com/openjdk/jdk/pull/11848 Something is causing high contention in the bot, it's under investigation. In the meantime, all you can do is retry this /integrate command until it goes through. - PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18 [v2]
On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi
wrote:
>> On jdk17, following testcase works fine on Linux platform.
>>
>> Testcase
>>
>> $ cat cstest1.java
>> import java.nio.charset.*;
>>
>> public class cstest1 {
>> public static void main(String[] args) throws Exception {
>> Charset cs = Charset.defaultCharset();
>> System.out.println(cs + ", " + cs.getClass() + ", " +
>> cs.getClass().getModule());
>> }
>> }
>>
>>
>> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "17.0.6" 2023-01-17
>> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
>> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode,
>> sharing)
>> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
>>
>>
>> But it does not work as expected on jdk18 and jdk21b06
>>
>> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "18.0.2.1" 2022-08-18
>> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
>> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode,
>> sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "21-ea" 2023-09-19
>> OpenJDK Runtime Environment (build 21-ea+6-365)
>> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>>
>>
>> Fixed result is as follows:
>>
>> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
>> openjdk version "21-internal" 2023-09-19
>> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
>> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode,
>> sharing)
>> x-IBM943C
>
> Ichiroh Takiguchi has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18
For the `jnuCharset` initialization revisit, I filed an issue:
https://bugs.openjdk.org/browse/JDK-8300916
-
PR: https://git.openjdk.org/jdk/pull/12132
Integrated: 8300077: Refactor code examples to use @snippet in java.text.ChoiceFormat
On Thu, 12 Jan 2023 22:31:24 GMT, Justin Lu wrote: > This PR implements _JEP 413: Code Snippets in Java API Documentation_ for > [java.text.ChoiceFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/ChoiceFormat.html). > > Code examples using ... blocks are replaced with the @ snippet > syntax where applicable. This pull request has now been integrated. Changeset: dcf1523b Author:Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/dcf1523bf2dba234371190a70a41cfcb77907196 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8300077: Refactor code examples to use @snippet in java.text.ChoiceFormat Reviewed-by: lancea, iris, naoto - PR: https://git.openjdk.org/jdk/pull/11981
Integrated: 8300866: Declare some classes final in java.io
On Mon, 23 Jan 2023 14:40:50 GMT, Per Minborg wrote: > This PR proposes declaring some internal classes in java.io as `final`, > explicitly indicating that they are not intended for sub-classing. > > If you think declaring classes final is just "static noice", please see > http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html > first and then come back and comment on the issue. This pull request has now been integrated. Changeset: d1173508 Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/d11735087507a17204bd81ae565409a3b7e881ae Stats: 15 lines in 5 files changed: 1 ins; 3 del; 11 mod 8300866: Declare some classes final in java.io Reviewed-by: alanb - PR: https://git.openjdk.org/jdk/pull/12141
Re: RFR: 8300866: Declare some classes final in java.io [v2]
> This PR proposes declaring some internal classes in java.io as `final`, > explicitly indicating that they are not intended for sub-classing. > > If you think declaring classes final is just "static noice", please see > http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html > first and then come back and comment on the issue. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge master - Declare classes as final - Changes: https://git.openjdk.org/jdk/pull/12141/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12141=01 Stats: 15 lines in 5 files changed: 1 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12141.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12141/head:pull/12141 PR: https://git.openjdk.org/jdk/pull/12141
Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
On Mon, 23 Jan 2023 11:58:58 GMT, Claes Redestad wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
>> Base64Encode.testBase64Encode 1024 thrpt3 4309.439 ± 2.632
>> ops/ms
>>
>>
>> **New:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score
>> Error Units
>> Base64Encode.testBase64Encode 1024 thrpt3 24211.397 ±
>> 102.026 ops/ms
>>
>>
>> Decode performance:
>> **Old:**
>>
>> Benchmark (errorIndex) (lineSize) (maxNumBytes)
>> Mode Cnt ScoreError Units
>> Base64Decode.testBase64Decode 144 4 1024
>> thrpt3 3961.768 ± 93.409 ops/ms
>>
>> **New:**
>> Benchmark (errorIndex) (lineSize) (maxNumBytes)
>> Mode Cnt ScoreError Units
>> Base64Decode.testBase64Decode 144 4 1024
>> thrpt3 14738.051 ± 24.383 ops/ms
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661:
>
>> 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit);
>> 2660: __ vmovdqu(xmm11, Address(r13, 0x28));
>> 2661: __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit);
>
> Sorry in advance since I'm probably reading this wrong: the data that `r13`
> is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does
> this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up
> their respective registers with the exact same bits? If so, and since neither
> of them is mutated in the code below, then perhaps this can be simplified a
> bit.
You're reading it correctly - this is redundant and could be handled
differently, as the same value is being loaded into ymm4 and ymm10. I don't
think there will be any significant performance gain either way. This was done
in this manner to allow easier transition to URL acceleration when it is
implemented, as URLs require handling '-' and '_' instead of '+' and '/' ('/' =
0x2f).
-
PR: https://git.openjdk.org/jdk/pull/12126
Re: RFR: 8300866: Declare some classes final in java.io
On Mon, 23 Jan 2023 18:06:26 GMT, Per Minborg wrote: > It looks like CE is used in `UnixFileSystem` via the system property > "sun.io.useCanonCaches" ? It was disabled in JDK 12 and the general plan was to eventually remove it eventually. - PR: https://git.openjdk.org/jdk/pull/12141
Re: RFR: 8300863: Remove C-style array declarations in java.io
On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg wrote: > Some variables are declared using old-style declarations. These should be > modified to conform to modern style. > > This is a task derived from https://github.com/openjdk/jdk/pull/11848 Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: 8300866: Declare some classes final in java.io
On Mon, 23 Jan 2023 18:02:44 GMT, Alan Bateman wrote: > Look okay. We should probably think about removing ExpiringCache as it hasn't > been used for many releases. It looks like CE is used in `UnixFileSystem` via the system property "sun.io.useCanonCaches" ? - PR: https://git.openjdk.org/jdk/pull/12141
Integrated: 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests
On Thu, 19 Jan 2023 20:43:11 GMT, Mandy Chung wrote: > `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations > and the test cases are executed in the warm up loop with 2 iterations to > verify C1, C2 intrinsics. Default Tier4CompileThreshold is 15000. > > This PR proposes to scale the compile threshold to 0.1 such that the warm up > loop can be reduced to 2000 iterations. This will speed up the test > execution time. > > > Before: > make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles 341.06s user > 14.65s system 563% cpu 1:03.14 total > > After: > make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles 234.38s user > 13.08s system 535% cpu 46.218 total This pull request has now been integrated. Changeset: 86fed796 Author:Mandy Chung URL: https://git.openjdk.org/jdk/commit/86fed79670c109fc3a7fbe1eb2b1485c6dd99e2f Stats: 202 lines in 27 files changed: 74 ins; 30 del; 98 mod 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests Reviewed-by: jvernee, dholmes, psandoz - PR: https://git.openjdk.org/jdk/pull/12104
Re: RFR: 8300866: Declare some classes final in java.io
On Mon, 23 Jan 2023 14:40:50 GMT, Per Minborg wrote: > This PR proposes declaring some internal classes in java.io as `final`, > explicitly indicating that they are not intended for sub-classing. > > If you think declaring classes final is just "static noice", please see > http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html > first and then come back and comment on the issue. Look okay. We should probably think about removing ExpiringCache as it hasn't been used for many releases. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12141
Re: RFR: 8300864: Declare some fields in java.io as final
On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg wrote: > Some of the fields in java.io can be declared as final. src/java.base/share/classes/java/io/File.java line 155: > 153: * The FileSystem object representing the platform's local file > system. > 154: */ > 155: private static final FileSystem FS = > DefaultFileSystem.getFileSystem(); It's a pity to rename this one as FS.* is very ugly. - PR: https://git.openjdk.org/jdk/pull/12140
Integrated: JDK-8300867: Fix document issues in java.io
On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg wrote: > This PR fixes a couple of typos in the documentation. This pull request has now been integrated. Changeset: 4525aa31 Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/4525aa318a1025e19d4ed9924ed25992be0075e9 Stats: 38 lines in 6 files changed: 0 ins; 0 del; 38 mod 8300867: Fix document issues in java.io Reviewed-by: alanb, lancea, iris - PR: https://git.openjdk.org/jdk/pull/12142
Integrated: 8300868: Reduce visibility in java.io.SerialCallbackContext
On Mon, 23 Jan 2023 15:08:47 GMT, Per Minborg wrote: > This PR proposes to reduce the visibility for constructor and methods in > `java.io.SerialCallbackContext`. This pull request has now been integrated. Changeset: a7f035db Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/a7f035db762ce44b72733094422488047c9ad738 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod 8300868: Reduce visibility in java.io.SerialCallbackContext Reviewed-by: rriggs - PR: https://git.openjdk.org/jdk/pull/12143
Integrated: 8300864: Declare some fields in java.io as final
On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg wrote: > Some of the fields in java.io can be declared as final. This pull request has now been integrated. Changeset: 079255e3 Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/079255e312a60584d748babcd320eacec99c5a02 Stats: 117 lines in 8 files changed: 5 ins; 5 del; 107 mod 8300864: Declare some fields in java.io as final Reviewed-by: rriggs, lancea - PR: https://git.openjdk.org/jdk/pull/12140
Re: RFR: 8300863: Remove C-style array declarations in java.io
On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg wrote: > Some variables are declared using old-style declarations. These should be > modified to conform to modern style. > > This is a task derived from https://github.com/openjdk/jdk/pull/11848 Nice cleanup. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface [v6]
On Sat, 21 Jan 2023 19:38:16 GMT, Sergey Bylokhov wrote: >> Tagir F. Valeev has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Whitespaces fixed >> - @implSpec added to shuffle(List) > > Filed, will create a PR soon. > https://bugs.openjdk.org/browse/JDK-8300817 @mrserb Thanks for noticing this and for cleaning up. Unfortunately the GitHub Actions are often broken spuriously, but this time it was a real issue. :-( - PR: https://git.openjdk.org/jdk/pull/10520
Re: RFR: JDK-8300867: Fix document issues in java.io
On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg wrote: > This PR fixes a couple of typos in the documentation. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12142
Re: RFR: JDK-8300867: Fix document issues in java.io
On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg wrote: > This PR fixes a couple of typos in the documentation. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12142
Re: RFR: 8300864: Declare some fields in java.io as final
On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg wrote: > Some of the fields in java.io can be declared as final. The changes look reasonable to me - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/12140
Re: RFR: 8300864: Declare some fields in java.io as final
On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg wrote: > Some of the fields in java.io can be declared as final. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12140
Re: RFR: 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests [v2]
On Fri, 20 Jan 2023 17:45:46 GMT, Mandy Chung wrote: >> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations >> and the test cases are executed in the warm up loop with 2 iterations to >> verify C1, C2 intrinsics. Default Tier4CompileThreshold is 15000. >> >> This PR proposes to scale the compile threshold to 0.1 such that the warm up >> loop can be reduced to 2000 iterations. This will speed up the test >> execution time. >> >> >> Before: >> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles 341.06s user >> 14.65s system 563% cpu 1:03.14 total >> >> After: >> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles 234.38s user >> 13.08s system 535% cpu 46.218 total > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > move the comment to @comment Marked as reviewed by psandoz (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12104
Re: RFR: JDK-8262994: Refactor String.split to help method inlining [v2]
On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer wrote: >> The method `String.split` contains a fast-path when the regular expression >> parameter is not really a regular expression, but just a single split >> character. >> This fast path vs. slow path check can be constant folded when the regular >> expression parameter is a literal constant - a quite frequent pattern (for >> example, all JDK usages of `String.split` have a constant expression >> parameter). But method inlining in JIT and AOT compilers can usually not >> inline `String.split` because the method body is too large. Factoring out >> the actual fast-path splitting logic into a separate method solves this >> problem: the JIT or AOT compiler can inline `String.split`, constant-fold >> the fast/slow path check, and then only the invoke of either the fast path >> or the slow path remains. > > Christian Wimmer has updated the pull request incrementally with one > additional commit since the last revision: > > Add comment about method inlining Can I get reviews and hopefully an approval to merge for this PR please. - PR: https://git.openjdk.org/jdk/pull/11791
Re: RFR: 8300863: Remove C-style array declarations in java.io
On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg wrote: > Some variables are declared using old-style declarations. These should be > modified to conform to modern style. > > This is a task derived from https://github.com/openjdk/jdk/pull/11848 Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: JDK-8300867: Fix document issues in java.io
On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg wrote: > This PR fixes a couple of typos in the documentation. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12142
Re: RFR: 8300863: Remove C-style array declarations in java.io
On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg wrote: > Some variables are declared using old-style declarations. These should be > modified to conform to modern style. > > This is a task derived from https://github.com/openjdk/jdk/pull/11848 Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: 8300868: Reduce visibility in java.io.SerialCallbackContext [v2]
On Mon, 23 Jan 2023 15:36:01 GMT, Per Minborg wrote: >> This PR proposes to reduce the visibility for constructor and methods in >> `java.io.SerialCallbackContext`. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright year Its a package private class, not really a significant change. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/12143
Re: RFR: 8300868: Reduce visibility in java.io.SerialCallbackContext [v2]
> This PR proposes to reduce the visibility for constructor and methods in > `java.io.SerialCallbackContext`. Per Minborg 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/12143/files - new: https://git.openjdk.org/jdk/pull/12143/files/6136a891..7f807539 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12143=01 - incr: https://webrevs.openjdk.org/?repo=jdk=12143=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12143.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12143/head:pull/12143 PR: https://git.openjdk.org/jdk/pull/12143
RFR: 8300868: Reduce visibility in java.io.SerialCallbackContext
This PR proposes to reduce the visibility for constructor and methods in `java.io.SerialCallbackContext`. - Commit messages: - Reduce visibility in j.i.SerialCallbackConext Changes: https://git.openjdk.org/jdk/pull/12143/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12143=00 Issue: https://bugs.openjdk.org/browse/JDK-8300868 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12143.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12143/head:pull/12143 PR: https://git.openjdk.org/jdk/pull/12143
RFR: JDK-8300867: Fix document issues in java.io
This PR fixes a couple of typos in the documentation. - Commit messages: - Update copyright year - Fix javadoc issues Changes: https://git.openjdk.org/jdk/pull/12142/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12142=00 Issue: https://bugs.openjdk.org/browse/JDK-8300867 Stats: 39 lines in 6 files changed: 0 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/12142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12142/head:pull/12142 PR: https://git.openjdk.org/jdk/pull/12142
RFR: 8300866: Declare some classes final in java.io
This PR proposes declaring some internal classes in java.io as `final`, explicitly indicating that they are not intended for sub-classing. If you think declaring classes final is just "static noice", please see http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html first and then come back and comment on the issue. - Commit messages: - Declare classes as final Changes: https://git.openjdk.org/jdk/pull/12141/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12141=00 Issue: https://bugs.openjdk.org/browse/JDK-8300866 Stats: 11 lines in 5 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12141.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12141/head:pull/12141 PR: https://git.openjdk.org/jdk/pull/12141
RFR: 8300864: Declare some fields in java.io as final
Some of the fields in java.io can be declared as final. - Commit messages: - Revert final class declaration - Declare fields final Changes: https://git.openjdk.org/jdk/pull/12140/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12140=00 Issue: https://bugs.openjdk.org/browse/JDK-8300864 Stats: 117 lines in 8 files changed: 5 ins; 5 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/12140.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12140/head:pull/12140 PR: https://git.openjdk.org/jdk/pull/12140
RFR: 8300863: Remove C-style array declarations in java.io
Some variables are declared using old-style declarations. These should be modified to conform to modern style. This is a task derived from https://github.com/openjdk/jdk/pull/11848 - Commit messages: - Fix more classes - Remove c-style declarations Changes: https://git.openjdk.org/jdk/pull/12139/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12139=00 Issue: https://bugs.openjdk.org/browse/JDK-8300863 Stats: 21 lines in 8 files changed: 1 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/12139.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12139/head:pull/12139 PR: https://git.openjdk.org/jdk/pull/12139
Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
On Sat, 21 Jan 2023 00:15:10 GMT, Scott Gibbons wrote: > Added code for Base64 acceleration (encode and decode) which will accelerate > ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3 4309.439 ± 2.632 > ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3 24211.397 ± 102.026 > ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode > Cnt ScoreError Units > Base64Decode.testBase64Decode 144 4 1024 thrpt >3 3961.768 ± 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode > Cnt ScoreError Units > Base64Decode.testBase64Decode 144 4 1024 thrpt >3 14738.051 ± 24.383 ops/ms src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661: > 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit); > 2660: __ vmovdqu(xmm11, Address(r13, 0x28)); > 2661: __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit); Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit. - PR: https://git.openjdk.org/jdk/pull/12126
Re: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18 [v2]
On Mon, 23 Jan 2023 09:44:48 GMT, Ichiroh Takiguchi wrote: > Java8 works `-Dfile.encoding=Cp943C` option on Linux. Since many users are > migrating from Java8, I'm getting similar requests from my clients. Cp943C is > not supported by Linux natively, but some clients want to use same encoding > with Linux and AIX. > > Japanese AIX environment supports IBM-943(Cp943C)/IBM-eucJP(Cp29626C)/UTF-8 > encoding. Cp943C and Cp29626C are in base.base module on AIX platform. It's never been supported to run with -Dfile.encoding=Cp943C. It may have worked in JDK 8 but I doubt it could have worked consistently since JDK 9 because the default charset is derived before it's possible to locate charset implementations outside of java.base. I think it would be useful to know a bit more about the environment. It sounds like it might be AIX -> Linux migration but I'm curious if you have any insight into why these applications depend on default charset being Cp943C. Is it text files that are opened without specifying the charset or is is something else? - PR: https://git.openjdk.org/jdk/pull/12132
Withdrawn: JDK-8297688: libjli leaks memory related to options handling
On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in > strings, taking ownership. Callers using dynamic memory free their storage > after calling `AddOption`. This ensures no memory is dropped on the floor. > This also removes the second argument to `AddOption` as it is unused and > shifts it into the source file. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11384
Withdrawn: 8299513: Clean up java.io
On Wed, 4 Jan 2023 15:37:23 GMT, Per Minborg wrote: > Code in java.io contains many legacy constructs and semantics not recommended > including: > > * C-style array declaration > * Unnecessary visibility > * Redundant keywords in interfaces (e.g. public, static) > * Non-standard naming for constants > * Javadoc typos > * Missing final declaration > > These should be fixed as a sanity effort. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11848
Re: RFR: 8299513: Clean up java.io [v9]
On Wed, 11 Jan 2023 15:31:22 GMT, Per Minborg wrote: >> Code in java.io contains many legacy constructs and semantics not >> recommended including: >> >> * C-style array declaration >> * Unnecessary visibility >> * Redundant keywords in interfaces (e.g. public, static) >> * Non-standard naming for constants >> * Javadoc typos >> * Missing final declaration >> >> These should be fixed as a sanity effort. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Convert field to static and revert copyright year I am closing this PR. I will create separate PRs for different classes of fixes. - PR: https://git.openjdk.org/jdk/pull/11848
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v5]
> This PR proposes using a performance optimization using a new supported API > for operations similar to those found in `java.io.Bits` Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove methods with implicit zero offset - Changes: - all: https://git.openjdk.org/jdk/pull/12076/files - new: https://git.openjdk.org/jdk/pull/12076/files/3a3dc2e0..a13b3603 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12076=04 - incr: https://webrevs.openjdk.org/?repo=jdk=12076=03-04 Stats: 333 lines in 3 files changed: 0 ins; 318 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/12076.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076 PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]
On Sun, 22 Jan 2023 13:28:06 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 2611:
>>
>>> 2609: "Cannot print as output of " + len + " characters
>>> exceeds pad width of " + padWidth);
>>> 2610: }
>>> 2611: buf.insert(preLen,
>>> String.valueOf(padChar).repeat(padWidth - len));
>>
>> Have you checked with a microbenchmark that this added allocation can be
>> elided by JITs and that there's a significant speed-up with your changes? I
>> don't have the necessary domain expertise to assert anything here but I
>> suspect padding widths are typically short. Such as 2 or 4 (for day/month
>> and year fields) so a micro should examine there's no regression for little
>> to no padding. Unlike the original code you call `insert` even if `padWidth
>> - len == 0`. This might be optimized away by JITs, but it'd be good to
>> verify which is best.
>
> The modified code is called only when a user explicitly calls `padNext(int,
> char)`, i.e. if I modified the example snippet as
>
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
> .appendLiteral("Date:")
> //.padNext(20, ' ')
> .append(DateTimeFormatter.ISO_DATE)
> .toFormatter();
> String text = dtf.format(LocalDateTime.now());
>
> there's no regression.
>
> Right now I cannot build ad-hoc JDK with my changes and check it with JMH, so
> I'd convert this to draft until I can verify it
Meant that you should verify that something like this, which just add a little
padding, doesn't regress with your changes:
DateTimeFormatter dtf = new DateTimeFormatterBuilder()
.appendLiteral("Year:")
.padNext(5)
.appendValue(ChronoField.YEAR)
.toFormatter();
...
dtf.format(LocalDateTime.now());
And similar for effectively no padding (`.padNext(4)` in the above example). As
this API might often be used to ensure short 2-4 char fields are correctly
padded I think it's important that we're not adding overhead to such use cases.
-
PR: https://git.openjdk.org/jdk/pull/12131
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v4]
On Mon, 23 Jan 2023 10:15:55 GMT, Per Minborg wrote: >> Very good question. I will take a look at it. A fixed value is inserted in >> the original var handle so potentially it might improve performance that way >> too. > > No significant performance increase: > > > 2-parameters > Benchmark Mode Cnt Score > Error Units > PrimitiveFieldSerializationBenchmark.serializeDataavgt8 6.761 ± > 0.126 ns/op > PrimitiveFieldSerializationBenchmark.serializeRecord avgt8 6.890 ± > 0.093 ns/op > > 3-parameters > Benchmark Mode Cnt Score > Error Units > PrimitiveFieldSerializationBenchmark.serializeDataavgt8 6.850 ± > 0.074 ns/op > PrimitiveFieldSerializationBenchmark.serializeRecord avgt8 6.855 ± > 0.057 ns/op I will remove the extra methods with lesser parameters. - PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v4]
On Mon, 23 Jan 2023 08:11:15 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java >> line 614: >> >>> 612: /* >>> 613: * Methods for packing primitive values into byte arrays starting >>> at offset zero. >>> 614: */ >> >> Is the only advantage to the zero offset versions in the API, shorter >> invocations with fewer parameters? >> Is there any performance difference? > > Very good question. I will take a look at it. A fixed value is inserted in > the original var handle so potentially it might improve performance that way > too. No significant performance increase: 2-parameters Benchmark Mode Cnt Score Error Units PrimitiveFieldSerializationBenchmark.serializeDataavgt8 6.761 ± 0.126 ns/op PrimitiveFieldSerializationBenchmark.serializeRecord avgt8 6.890 ± 0.093 ns/op 3-parameters Benchmark Mode Cnt Score Error Units PrimitiveFieldSerializationBenchmark.serializeDataavgt8 6.850 ± 0.074 ns/op PrimitiveFieldSerializationBenchmark.serializeRecord avgt8 6.855 ± 0.057 ns/op - PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18 [v2]
On Mon, 23 Jan 2023 07:48:41 GMT, Alan Bateman wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8300819: -Dfile.encoding=Cp943C option does not work as expected since >> jdk18 > > I'm trying to understand what the real issue is. The java.base module on > Linux builds includes SJIS, MS932, and PCK. Is there a Linux configuration in > Japanese environments where the default charset in any JDK release is > IBM943C? Same question for AIX builds that is the only build that includes > IBM943C in java.base. Hello @AlanBateman . Sorry for your confusion. Java8 works `-Dfile.encoding=Cp943C` option on Linux. Since many users are migrating from Java8, I'm getting similar requests from my clients. Cp943C is not supported by Linux natively, but some clients want to use same encoding with Linux and AIX. Japanese AIX environment supports IBM-943(Cp943C)/IBM-eucJP(Cp29626C)/UTF-8 encoding. Cp943C and Cp29626C are in base.base module on AIX platform. - PR: https://git.openjdk.org/jdk/pull/12132
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v4]
> This PR proposes using a performance optimization using a new supported API > for operations similar to those found in `java.io.Bits` Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add benchmark - Changes: - all: https://git.openjdk.org/jdk/pull/12076/files - new: https://git.openjdk.org/jdk/pull/12076/files/badf281d..3a3dc2e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12076=03 - incr: https://webrevs.openjdk.org/?repo=jdk=12076=02-03 Stats: 150 lines in 1 file changed: 150 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12076.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076 PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v3]
> This PR proposes using a performance optimization using a new supported API > for operations similar to those found in `java.io.Bits` Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename and move - Changes: - all: https://git.openjdk.org/jdk/pull/12076/files - new: https://git.openjdk.org/jdk/pull/12076/files/f9280814..badf281d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12076=02 - incr: https://webrevs.openjdk.org/?repo=jdk=12076=01-02 Stats: 1038 lines in 9 files changed: 470 ins; 470 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/12076.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076 PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v2]
> This PR proposes using a performance optimization using a new supported API > for operations similar to those found in `java.io.Bits` Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Improve doc and fix typo - Changes: - all: https://git.openjdk.org/jdk/pull/12076/files - new: https://git.openjdk.org/jdk/pull/12076/files/ce1d5765..f9280814 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=12076=01 - incr: https://webrevs.openjdk.org/?repo=jdk=12076=00-01 Stats: 69 lines in 2 files changed: 0 ins; 37 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/12076.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076 PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes [v2]
On Fri, 20 Jan 2023 18:21:59 GMT, Roger Riggs wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Improve doc and fix typo > > src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java > line 614: > >> 612: /* >> 613: * Methods for packing primitive values into byte arrays starting >> at offset zero. >> 614: */ > > Is the only advantage to the zero offset versions in the API, shorter > invocations with fewer parameters? > Is there any performance difference? Very good question. I will take a look at it. A fixed value is inserted in the original var handle so potentially it might improve performance that way too. - PR: https://git.openjdk.org/jdk/pull/12076
[jdk20] Integrated: 8290919: Update nroff pages in JDK 20 before RC
On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes wrote: > There was one missing update in javac.1 from: > > [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate > -profile option in javac > > otherwise the change is limited to dropping the "-ea". > > Thanks. This pull request has now been integrated. Changeset: fd752178 Author:David Holmes URL: https://git.openjdk.org/jdk20/commit/fd752178e364fb5deeec062bef3dde1fea1dcbe3 Stats: 29 lines in 28 files changed: 1 ins; 0 del; 28 mod 8290919: Update nroff pages in JDK 20 before RC Reviewed-by: iris, alanb - PR: https://git.openjdk.org/jdk20/pull/112
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes
On Mon, 23 Jan 2023 07:56:08 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java >> line 26: >> >>> 24: */ >>> 25: >>> 26: package jdk.internal.util.access; >> >> This is pretty deep; I'd drop the final "access". The package name >> `jdk.internal.util` is fine. > > Happy to rename to `ByteArray` if we keep the package. The reason for > proposing a separate package is that if we later decide to export the class, > we are able to `export to` only this package and not all the other classes in > `jdk.internal.util'. This could reduce coupling. "access" in the package/class name does look a bit strange, and could easily get mixed up with the package and classes that are used for shared secrets. I don't think jdk.internal.util.ByteArrays would look out of place. Hopefully it won't need to be exported to many other modules as we need to keep the qualified exports to a minimum. - PR: https://git.openjdk.org/jdk/pull/12076
Re: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream classes
On Fri, 20 Jan 2023 16:36:23 GMT, Roger Riggs wrote: >> This PR proposes using a performance optimization using a new supported API >> for operations similar to those found in `java.io.Bits` > > src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java > line 26: > >> 24: */ >> 25: >> 26: package jdk.internal.util.access; > > This is pretty deep; I'd drop the final "access". The package name > `jdk.internal.util` is fine. Happy to rename to `ByteArray` if we keep the package. The reason for proposing a separate package is that if we later decide to export the class, we are able to `export to` only this package and not all the other classes in `jdk.internal.util'. This could reduce coupling. - PR: https://git.openjdk.org/jdk/pull/12076
