Re: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home
On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare
wrote:
> This concerns [dtdbuilder
> tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder).
>
> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`.
>
> So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home`
> string value is not `null`, causing an exception with the present test.
>
> The expected value is `"Must set property 'dtd_home'"`
>
> And in this case, should'nt we have a `System.exit(1)` too rather than a
> simple `return` ?
>
-
PR: https://git.openjdk.java.net/jdk/pull/3626
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3]
On Tue, 8 Jun 2021 00:30:38 GMT, Scott Gibbons wrote: >> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. >> Also allows for performance improvement for non-AVX-512 enabled platforms. >> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to >> accept an additional parameter (isMIME) for fast-path MIME decoding. >> >> A change was made to the signature of DecodeBlock in Base64.java to provide >> the intrinsic information as to whether MIME decoding was being done. This >> allows for the intrinsic to bypass the expensive setup of zmm registers from >> AVX tables, knowing there may be invalid Base64 characters every 76 >> characters or so. A change was also made here removing the restriction that >> the intrinsic must return an even multiple of 3 bytes decoded. This >> implementation handles the pad characters at the end of the string and will >> return the actual number of characters decoded. >> >> The AVX portion of this code will decode in blocks of 256 bytes per loop >> iteration, then in chunks of 64 bytes, followed by end fixup decoding. The >> non-AVX code is an assembly-optimized version of the java DecodeBlock and >> behaves identically. >> >> Running the Base64Decode benchmark, this change increases decode performance >> by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers >> are given in the table below. >> >> **Base Score** is without intrinsic support, **Optimized Score** is using >> this intrinsic, and **Gain** is **Base** / **Optimized**. >> >> >> Benchmark Name | Base Score | Optimized Score | Gain >> -- | -- | -- | -- >> testBase64Decode size 1 | 15.36 | 15.32 | 1.00 >> testBase64Decode size 3 | 17.00 | 16.72 | 1.02 >> testBase64Decode size 7 | 20.60 | 18.82 | 1.09 >> testBase64Decode size 32 | 34.21 | 26.77 | 1.28 >> testBase64Decode size 64 | 54.43 | 38.35 | 1.42 >> testBase64Decode size 80 | 66.40 | 48.34 | 1.37 >> testBase64Decode size 96 | 73.16 | 52.90 | 1.38 >> testBase64Decode size 112 | 84.93 | 51.82 | 1.64 >> testBase64Decode size 512 | 288.81 | 32.04 | 9.01 >> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 >> testBase64Decode size 2 | 9530.28 | 483.37 | 19.72 >> testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15 >> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 >> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 >> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 >> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 >> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 >> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 >> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 >> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 >> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 >> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 >> testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09 >> testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21 >> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 >> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 >> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 >> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 >> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 >> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 >> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 >> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 >> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 >> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 >> testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23 >> testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26 > > Scott Gibbons has updated the pull request incrementally with one additional > commit since the last revision: > > Fixing review comments. Adding notes about isMIME parameter for other > architectures; clarifying decodeBlock comments. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6239: > 6237: > 6238: __ align(32); > 6239: __ BIND(L_bruteForce); Is this alignment needed ? Given that brute force loop is already aligned. - PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8265440: IGV: make node selection more visible
On Wed, 2 Jun 2021 06:22:44 GMT, Koichi Sakata wrote: > This pull request makes node selection more visible. > > At present when selecting node, node name is bolder. In addition to that, > thickness of the border is bolder after applying this code. > > I tested manually. Here are the images that I took before and after applying > this patch as follows. > > ### After Applying the Code > src="https://user-images.githubusercontent.com/60008/120432008-425f3f00-c3b4-11eb-91ed-2f940279affd.png";> width="300" alt="スクリーンショット 2021-06-02 14 40 43" > src="https://user-images.githubusercontent.com/60008/120432019-44c19900-c3b4-11eb-81ad-9412869e1c28.png";> > > Left: "0 Root" and "3 Start" are selected. > Right: "0 Root" and "3 Start" are selected. "3 Start" and "7 Parm" are > highlighted. > > src="https://user-images.githubusercontent.com/60008/120432028-468b5c80-c3b4-11eb-8673-9172761a15b2.png";> width="200" alt="スクリーンショット 2021-06-02 14 44 11" > src="https://user-images.githubusercontent.com/60008/120432029-4723f300-c3b4-11eb-833e-f6cb8dd30129.png";> > > Left: The upper right slot of "20 MergeMem" are selected. > Right: The upper right slot of "20 MergeMem" are selected and highlighted. > > ### Before Applying the Code > src="https://user-images.githubusercontent.com/60008/120432024-45f2c600-c3b4-11eb-879d-7977caaa0e39.png";> width="300" alt="スクリーンショット 2021-06-02 14 42 29" > src="https://user-images.githubusercontent.com/60008/120432025-45f2c600-c3b4-11eb-85ed-6dd8a0c8ff60.png";> > > Left: "0 Root" and "3 Start" are selected. > Right: "0 Root" and "3 Start" are selected. "3 Start" and "7 Parm" are > highlighted. Could someone possibly sponsor this pull request? Thanks, Koichi - PR: https://git.openjdk.java.net/jdk/pull/4298
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3]
> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. > Also allows for performance improvement for non-AVX-512 enabled platforms. > Due to the nature of MIME-encoded inputs, modify the intrinsic signature to > accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide > the intrinsic information as to whether MIME decoding was being done. This > allows for the intrinsic to bypass the expensive setup of zmm registers from > AVX tables, knowing there may be invalid Base64 characters every 76 > characters or so. A change was also made here removing the restriction that > the intrinsic must return an even multiple of 3 bytes decoded. This > implementation handles the pad characters at the end of the string and will > return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop > iteration, then in chunks of 64 bytes, followed by end fixup decoding. The > non-AVX code is an assembly-optimized version of the java DecodeBlock and > behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance > by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers > are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using > this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 2 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fixing review comments. Adding notes about isMIME parameter for other architectures; clarifying decodeBlock comments. - Changes: - all: https://git.openjdk.java.net/jdk/pull/4368/files - new: https://git.openjdk.java.net/jdk/pull/4368/files/00fd5621..d66e32e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=01-02 Stats: 19 lines in 3 files changed: 8 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2]
On Tue, 8 Jun 2021 00:11:42 GMT, Scott Gibbons
wrote:
>> src/java.base/share/classes/java/util/Base64.java line 813:
>>
>>> 811: while (sp < sl) {
>>> 812: if (shiftto == 18 && sp < sl - 4) { // fast path
>>> 813: int dl = decodeBlock(src, sp, sl, dst, dp, isURL,
>>> isMIME);
>>
>> This new param is passed all the way down to the intrinsic. I think
>> existing intrinsics can safely ignore this parameter if it doesn't help the
>> implementation (for example PPC64-LE has 16-byte vector registers, so isn't
>> quite as seriously impacted by MIME). However, in the code for the PPC64-LE
>> intrinsic, this new parameter isn't mentioned. I think if you're going to
>> add a new parameter, it should be mentioned in the existing intrinsics as
>> being present, but unused.
>
> Are you suggesting that I change *all* intrinsic implementations (aarch64,
> ppc, etc.)? I have no problem doing that - just checking if this is what's
> desired.
Yes. I didn't realize that there's a decodeBlock intrinsic for aarch64 already,
but yeah it should only be a couple of lines of comments for each.
-
PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2]
On Mon, 7 Jun 2021 22:34:33 GMT, Corey Ashford wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update full name
>
> src/java.base/share/classes/java/util/Base64.java line 813:
>
>> 811: while (sp < sl) {
>> 812: if (shiftto == 18 && sp < sl - 4) { // fast path
>> 813: int dl = decodeBlock(src, sp, sl, dst, dp, isURL,
>> isMIME);
>
> This new param is passed all the way down to the intrinsic. I think existing
> intrinsics can safely ignore this parameter if it doesn't help the
> implementation (for example PPC64-LE has 16-byte vector registers, so isn't
> quite as seriously impacted by MIME). However, in the code for the PPC64-LE
> intrinsic, this new parameter isn't mentioned. I think if you're going to
> add a new parameter, it should be mentioned in the existing intrinsics as
> being present, but unused.
Are you suggesting that I change *all* intrinsic implementations (aarch64, ppc,
etc.)? I have no problem doing that - just checking if this is what's desired.
> src/java.base/share/classes/java/util/Base64.java line 818:
>
>> 816: * bytes of data were returned.
>> 817: */
>> 818: int chars_decoded = ((dl + 2) / 3) * 4;
>
> In the PR comments, you say, "A change was also made here removing the
> restriction that the intrinsic must return an even multiple of 3 bytes
> decoded.", however there's still a comment in the code above that says:
>
> * If the intrinsic function does not process all of the bytes in
> * src, it must process a multiple of four of them, making the
> * returned destination length a multiple of three.
>
> So this comment needs to be changed or removed to reflect your commit.
I will change the comment, and add verbage regarding the new parameter. Thank
you.
-
PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2]
On Mon, 7 Jun 2021 13:20:20 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>> accept an additional parameter (isMIME) for fast-path MIME decoding.
>>
>> A change was made to the signature of DecodeBlock in Base64.java to provide
>> the intrinsic information as to whether MIME decoding was being done. This
>> allows for the intrinsic to bypass the expensive setup of zmm registers from
>> AVX tables, knowing there may be invalid Base64 characters every 76
>> characters or so. A change was also made here removing the restriction that
>> the intrinsic must return an even multiple of 3 bytes decoded. This
>> implementation handles the pad characters at the end of the string and will
>> return the actual number of characters decoded.
>>
>> The AVX portion of this code will decode in blocks of 256 bytes per loop
>> iteration, then in chunks of 64 bytes, followed by end fixup decoding. The
>> non-AVX code is an assembly-optimized version of the java DecodeBlock and
>> behaves identically.
>>
>> Running the Base64Decode benchmark, this change increases decode performance
>> by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers
>> are given in the table below.
>>
>> **Base Score** is without intrinsic support, **Optimized Score** is using
>> this intrinsic, and **Gain** is **Base** / **Optimized**.
>>
>>
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 2 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update full name
Thanks for making this interesting update, which improves the flexibility of
intrinsics to make use of isMIME.
src/java.base/share/classes/java/util/Base64.java line 813:
> 811: while (sp < sl) {
> 812: if (shiftto == 18 && sp < sl - 4) { // fast path
> 813: int dl = decodeBlock(src, sp, sl, dst, dp, isURL,
> isMIME);
This new param is passed all the way down to the intrinsic. I think existing
intrinsics can safely ignore this parameter if it doesn't help the
implementation (for example PPC64-LE has 16-byte vector registers, so isn't
quite as seriously impacted by MIME). However, in the code for the PPC64-LE
intrinsic, this new parameter isn't mentioned. I think if you're going to add
a new parameter, it should be mentioned in the existing intrinsics as being
present, but unused.
src/java.base/share/classes/java/util/Base64.java line 818:
> 816: * bytes of data were returned.
> 817: */
> 818
Re: RFR: 8267630: Start of release updates for JDK 18 [v5]
On Mon, 7 Jun 2021 19:38:58 GMT, Joe Darcy wrote: >> 8267630: Start of release updates for JDK 18 > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 17 additional commits since > the last revision: > > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Update symbols for JDK 17 b25. > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - ... and 7 more: > https://git.openjdk.java.net/jdk/compare/41bce524...34480e50 Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4175
Re: RFR: JDK-8263468: New page for "recent" new API [v2]
On Mon, 7 Jun 2021 14:53:55 GMT, Jonathan Gibbons wrote:
>> Hannes Wallnöfer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263468: automate build integration
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
> line 268:
>
>> 266: doclet.help.new.body=\
>> 267: The {0} page lists APIs that have been added in recent releases. \
>> 268: The content of this page is based on information provided by
>> Javadoc @since tags.
>
> Either change to "JavaDoc" or (preferably?) just delete this word, or even
> the sentence.
>
> Is there any interaction with `-nosince`? Should there be?
I removed the second sentence.
There is no interaction with `-nosince`. I one point I thought `-nosince`
should disable this feature, but actually both features are just different ways
of displaying the information stored in `@since` tags that don't depend on each
other.
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java
> line 337:
>
>> 335: */
>> 336: public int getSourceVersionNumber() {
>> 337: return configuration.docEnv.getSourceVersion().ordinal();
>
> As a general comment, I believe Joe does not encourage use of `ordinal`
I undid this change as it's not really part of the feature.
-
PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: JDK-8263468: New page for "recent" new API [v3]
On Mon, 7 Jun 2021 15:27:21 GMT, Jonathan Gibbons wrote: >> Hannes Wallnöfer has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into JDK-8263468 >> - JDK-8263468: automate build integration >> - JDK-8263468: make constant static >> - JDK-8263468: Remove unused DocPaths methods >> - JDK-8263468: Cleanup >> - JDK-8263468: Add tests >> - JDK-8263468: Update to new Table methods >> - Merge branch 'master' into JDK-8263468 >> >># Conflicts: >># >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css >> - JDK-8263468: Fix tests >> - JDK-8263468: Update to latest CSR >> - ... and 6 more: >> https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java > line 49: > >> 47: /** >> 48: * Generate File to list all the new API elements with the >> 49: * appropriate links. > > (minor) not standard form of comment, but it's "only" an internal class, so > could be fixed up later This comment and the comment below was copied and adapter from another SummaryListWriter subclass. I took the liberty of rewriting both comments. - PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: JDK-8263468: New page for "recent" new API [v2]
On Mon, 7 Jun 2021 14:52:57 GMT, Jonathan Gibbons wrote: >> Hannes Wallnöfer has updated the pull request incrementally with one >> additional commit since the last revision: >> >> JDK-8263468: automate build integration > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties > line 112: > >> 110: doclet.Deprecated_Tabs_Intro=(The leftmost tab "Deprecated ..." >> indicates all the \ >> 111: deprecated elements, regardless of the releases in which they were >> deprecated. \ >> 112: Each of the righthand tabs "Deprecated in ..." indicates the >> elements deprecated \ > > "Each of the righthand" doesn't read well. Would "Each of the other" be > better? Changed to "Each of the other". - PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: JDK-8263468: New page for "recent" new API [v4]
> This adds a new kind of summary list for new API added in specific releases, > and adds information to the deprecated API list about elements that were > deprecated in the given releases. > > The changes to the code are relatively minor thanks to the existing > infrastructure for summary list pages, which was extended by adding the > `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in > order to generate tabbed tables. > > One important area that needs to be reviewed is the addition of resources in > `standard.properties`. A relatively big share of discussion and effort went > into shaping the UI messages. > > The build system change adds options to generate API changes for all releases > after JDK 11, with "New API since JDK 11" as page title for the new API page. > I uploaded the generated documentation here: > > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html Hannes Wallnöfer has updated the pull request incrementally with one additional commit since the last revision: JDK-8263468: review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/4209/files - new: https://git.openjdk.java.net/jdk/pull/4209/files/3b13ae32..c9c5f832 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=02-03 Stats: 29 lines in 7 files changed: 6 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/4209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4209/head:pull/4209 PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: 8267630: Start of release updates for JDK 18 [v5]
> 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/947ea6f5...34480e50 - Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/f926c1bc..34480e50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=03-04 Stats: 24229 lines in 300 files changed: 22483 ins; 936 del; 810 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175
Integrated: 8268296: ScopedMemoryAccess build error with readonly filesystems
On Sun, 6 Jun 2021 20:09:32 GMT, Liam Miller-Cushon wrote: > This change fixes a build error during the generation of > `ScopedMemoryAccess.java` when the sources are readonly, by using `cat a > b` > instead of `cp a b` to avoid propagating the permissions to the generated > source. This pull request has now been integrated. Changeset: e546ae27 Author:Liam Miller-Cushon URL: https://git.openjdk.java.net/jdk/commit/e546ae27ffc6c19ae078a41ab6e1741a104958c1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268296: ScopedMemoryAccess build error with readonly filesystems Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/4380
Re: RFR: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac
On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov wrote: > I got rid of `realpath` usage as discussed in > https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro > instead, however there were quite a few problems with this macro, here's the > example: > > $(call RelativePath,/foo/bar,/foo/bar/baz) -> "..//foo/bar" > $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT > $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> "./baz/banan" > $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> "../baz" > > As you can see, 1st case is just plain wrong, 2nd crashes make because of > infinite loop, 3rd can be simplified and all of them have leading whitespaces > First commit in this PR fixes all these issues and adds corresponding test > cases and second commit replaces usage of `realpath` in idea.sh with > `RelativePath` macro in idea.gmk and fixes problems, when paths are > incorrectly treated by IDEA All builds passed, approved. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4369
Integrated: 8268299: jvms tag produces incorrect URL
On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL > looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS > and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. This pull request has now been integrated. Changeset: e663ba96 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/e663ba961f25c83758815bbfce97a58d9560c7a2 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8268299: jvms tag produces incorrect URL Reviewed-by: iris, erikj, jjg - PR: https://git.openjdk.java.net/jdk/pull/4381
Re: RFR: 8268299: jvms tag produces incorrect URL
On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL > looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS > and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. Marked as reviewed by jjg (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4381
Re: RFR: JDK-8263468: New page for "recent" new API [v3]
On Mon, 7 Jun 2021 15:46:45 GMT, Jonathan Gibbons wrote:
>> Hannes Wallnöfer has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 16 commits:
>>
>> - Merge branch 'master' into JDK-8263468
>> - JDK-8263468: automate build integration
>> - JDK-8263468: make constant static
>> - JDK-8263468: Remove unused DocPaths methods
>> - JDK-8263468: Cleanup
>> - JDK-8263468: Add tests
>> - JDK-8263468: Update to new Table methods
>> - Merge branch 'master' into JDK-8263468
>>
>># Conflicts:
>>#
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
>> - JDK-8263468: Fix tests
>> - JDK-8263468: Update to latest CSR
>> - ... and 6 more:
>> https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32
>
> test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/module-info.java line 30:
>
>> 28: module mdl {
>> 29: exports pkg;
>> 30: }
>
> final newline
For all these "sample API" source files, they are OK, but another time,
consider the use of possibly-custom builders, to generate these files
dynamically. and to make for more concise reading.
-
PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: JDK-8263468: New page for "recent" new API [v3]
On Mon, 7 Jun 2021 15:00:43 GMT, Hannes Wallnöfer wrote:
>> This adds a new kind of summary list for new API added in specific releases,
>> and adds information to the deprecated API list about elements that were
>> deprecated in the given releases.
>>
>> The changes to the code are relatively minor thanks to the existing
>> infrastructure for summary list pages, which was extended by adding the
>> `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in
>> order to generate tabbed tables.
>>
>> One important area that needs to be reviewed is the addition of resources in
>> `standard.properties`. A relatively big share of discussion and effort went
>> into shaping the UI messages.
>>
>> The build system change adds options to generate API changes for all
>> releases after JDK 11, with "New API since JDK 11" as page title for the new
>> API page. I uploaded the generated documentation here:
>>
>> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html
>> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html
>
> Hannes Wallnöfer has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 16 commits:
>
> - Merge branch 'master' into JDK-8263468
> - JDK-8263468: automate build integration
> - JDK-8263468: make constant static
> - JDK-8263468: Remove unused DocPaths methods
> - JDK-8263468: Cleanup
> - JDK-8263468: Add tests
> - JDK-8263468: Update to new Table methods
> - Merge branch 'master' into JDK-8263468
>
># Conflicts:
>#
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
> - JDK-8263468: Fix tests
> - JDK-8263468: Update to latest CSR
> - ... and 6 more:
> https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java
line 49:
> 47: /**
> 48: * Generate File to list all the new API elements with the
> 49: * appropriate links.
(minor) not standard form of comment, but it's "only" an internal class, so
could be fixed up later
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java
line 72:
> 70: /**
> 71: * Get list of all the new elements.
> 72: * Then instantiate NewAPIListWriter and generate File.
Comment. Looks like it may have been copied from elsewhere, I guess
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
line 726:
> 724: */
> 725: deprecatedInReleasePage,
> 726:
Note to self ... affects new "Output Generated " document
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java
line 145:
> 143: public static final DocPath PACKAGE_USE =
> DocPath.create("package-use.html");
> 144:
> 145: /** The name of the fie for preview elements. */
typo: "fie"
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java
line 148:
> 146: public static final DocPath PREVIEW_LIST =
> DocPath.create("preview-list.html");
> 147:
> 148: /** The name of the fie for new elements. */
typo "fie"
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
line 1526:
> 1524: }
> 1525:
> 1526: // Returns the Deprecated annotation element value of the given
> element, or null.
Use `/**...*/`
test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/module-info.java line 30:
> 28: module mdl {
> 29: exports pkg;
> 30: }
final newline
-
PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: JDK-8263468: New page for "recent" new API [v2]
On Fri, 28 May 2021 08:19:33 GMT, Hannes Wallnöfer wrote:
>> This adds a new kind of summary list for new API added in specific releases,
>> and adds information to the deprecated API list about elements that were
>> deprecated in the given releases.
>>
>> The changes to the code are relatively minor thanks to the existing
>> infrastructure for summary list pages, which was extended by adding the
>> `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in
>> order to generate tabbed tables.
>>
>> One important area that needs to be reviewed is the addition of resources in
>> `standard.properties`. A relatively big share of discussion and effort went
>> into shaping the UI messages.
>>
>> The build system change adds options to generate API changes for all
>> releases after JDK 11, with "New API since JDK 11" as page title for the new
>> API page. I uploaded the generated documentation here:
>>
>> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html
>> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html
>
> Hannes Wallnöfer has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8263468: automate build integration
Some minor suggestions for your consideration
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
line 112:
> 110: doclet.Deprecated_Tabs_Intro=(The leftmost tab "Deprecated ..."
> indicates all the \
> 111: deprecated elements, regardless of the releases in which they were
> deprecated. \
> 112: Each of the righthand tabs "Deprecated in ..." indicates the
> elements deprecated \
"Each of the righthand" doesn't read well. Would "Each of the other" be
better?
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
line 119:
> 117: doclet.New_Label=New
> 118: doclet.New_Tabs_Intro=(The leftmost tab "New ..." indicates all the new
> elements, \
> 119: regardless of the releases in which they were added. Each of the
> righthand \
ditto
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
line 268:
> 266: doclet.help.new.body=\
> 267: The {0} page lists APIs that have been added in recent releases. \
> 268: The content of this page is based on information provided by Javadoc
> @since tags.
Either change to "JavaDoc" or (preferably?) just delete this word, or even the
sentence.
Is there any interaction with `-nosince`? Should there be?
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java
line 337:
> 335: */
> 336: public int getSourceVersionNumber() {
> 337: return configuration.docEnv.getSourceVersion().ordinal();
As a general comment, I believe Joe does not encourage use of `ordinal`
-
PR: https://git.openjdk.java.net/jdk/pull/4209
Re: RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10
On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote: > Hi, > > The documentation of `CLinker::systemLookup` [1] says this: > > > * Obtains a system lookup which is suitable to find symbols in the standard C > libraries. > > > However, currently it is not possible to look up common stdio.h symbols, such > as `printf`, using the system lookup on Windows 10. This is because the > backing library that is loaded, namely `ucrtbase.dll`, does not contain these > symbols, as they are implemented in the standard library as inline functions. > > This patch changes the system lookup implementation on Windows 10 to make > these symbols findable as well, by using a fallback library that forces the > generation of the code for the inline functions, and exposes the missing > symbols as a table of function pointers. > > See also the prior review of this patch for the panama-foreign repo: > https://github.com/openjdk/panama-foreign/pull/547 > > Since the exact set of symbols findable by the system lookup is unspecified, > and since the API in question (`CLinker::systemLookup`) was added only last > week [2], I've elected to not create a CSR for this patch, but please let me > know if one is needed). > > Thanks, > Jorn > > [1] : > https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 > [2] : > https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab LGTM - Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4390
Re: RFR: JDK-8263468: New page for "recent" new API [v3]
> This adds a new kind of summary list for new API added in specific releases, > and adds information to the deprecated API list about elements that were > deprecated in the given releases. > > The changes to the code are relatively minor thanks to the existing > infrastructure for summary list pages, which was extended by adding the > `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in > order to generate tabbed tables. > > One important area that needs to be reviewed is the addition of resources in > `standard.properties`. A relatively big share of discussion and effort went > into shaping the UI messages. > > The build system change adds options to generate API changes for all releases > after JDK 11, with "New API since JDK 11" as page title for the new API page. > I uploaded the generated documentation here: > > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html Hannes Wallnöfer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into JDK-8263468 - JDK-8263468: automate build integration - JDK-8263468: make constant static - JDK-8263468: Remove unused DocPaths methods - JDK-8263468: Cleanup - JDK-8263468: Add tests - JDK-8263468: Update to new Table methods - Merge branch 'master' into JDK-8263468 # Conflicts: # src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css - JDK-8263468: Fix tests - JDK-8263468: Update to latest CSR - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3396b69f...3b13ae32 - Changes: https://git.openjdk.java.net/jdk/pull/4209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=02 Stats: 1925 lines in 41 files changed: 1846 ins; 38 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/4209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4209/head:pull/4209 PR: https://git.openjdk.java.net/jdk/pull/4209
Integrated: 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs
On Fri, 4 Jun 2021 15:53:42 GMT, Weijun Wang wrote: > Now that the default behavior of JDK 17 is still > `-Djava.security.manager=allow`, we can remove the > `-Djavatest.security.noSecurityManager=true` option from the jtreg command > line inside `RunTests.gmk`. Three problem-listed langtools tests can also be > liberated. This pull request has now been integrated. Changeset: a91f9712 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/a91f97126646f89d8c5b81cfd40820338c769acd Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs Reviewed-by: lancea, jjg, erikj - PR: https://git.openjdk.java.net/jdk/pull/4364
Re: RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10
On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote: > Hi, > > The documentation of `CLinker::systemLookup` [1] says this: > > > * Obtains a system lookup which is suitable to find symbols in the standard C > libraries. > > > However, currently it is not possible to look up common stdio.h symbols, such > as `printf`, using the system lookup on Windows 10. This is because the > backing library that is loaded, namely `ucrtbase.dll`, does not contain these > symbols, as they are implemented in the standard library as inline functions. > > This patch changes the system lookup implementation on Windows 10 to make > these symbols findable as well, by using a fallback library that forces the > generation of the code for the inline functions, and exposes the missing > symbols as a table of function pointers. > > See also the prior review of this patch for the panama-foreign repo: > https://github.com/openjdk/panama-foreign/pull/547 > > Since the exact set of symbols findable by the system lookup is unspecified, > and since the API in question (`CLinker::systemLookup`) was added only last > week [2], I've elected to not create a CSR for this patch, but please let me > know if one is needed). > > Thanks, > Jorn > > [1] : > https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 > [2] : > https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab Build change looks good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4390
RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10
Hi, The documentation of `CLinker::systemLookup` [1] says this: * Obtains a system lookup which is suitable to find symbols in the standard C libraries. However, currently it is not possible to look up common stdio.h symbols, such as `printf`, using the system lookup on Windows 10. This is because the backing library that is loaded, namely `ucrtbase.dll`, does not contain these symbols, as they are implemented in the standard library as inline functions. This patch changes the system lookup implementation on Windows 10 to make these symbols findable as well, by using a fallback library that forces the generation of the code for the inline functions, and exposes the missing symbols as a table of function pointers. See also the prior review of this patch for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/547 Since the exact set of symbols findable by the system lookup is unspecified, and since the API in question (`CLinker::systemLookup`) was added only last week [2], I've elected to not create a CSR for this patch, but please let me know if one is needed). Thanks, Jorn [1] : https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 [2] : https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab - Commit messages: - Upstream 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Changes: https://git.openjdk.java.net/jdk/pull/4390/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4390&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268327 Stats: 273 lines in 5 files changed: 203 ins; 58 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4390/head:pull/4390 PR: https://git.openjdk.java.net/jdk/pull/4390
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2]
> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. > Also allows for performance improvement for non-AVX-512 enabled platforms. > Due to the nature of MIME-encoded inputs, modify the intrinsic signature to > accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide > the intrinsic information as to whether MIME decoding was being done. This > allows for the intrinsic to bypass the expensive setup of zmm registers from > AVX tables, knowing there may be invalid Base64 characters every 76 > characters or so. A change was also made here removing the restriction that > the intrinsic must return an even multiple of 3 bytes decoded. This > implementation handles the pad characters at the end of the string and will > return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop > iteration, then in chunks of 64 bytes, followed by end fixup decoding. The > non-AVX code is an assembly-optimized version of the java DecodeBlock and > behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance > by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers > are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using > this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 2 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update full name - Changes: - all: https://git.openjdk.java.net/jdk/pull/4368/files - new: https://git.openjdk.java.net/jdk/pull/4368/files/e527557a..00fd5621 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8268299: jvms tag produces incorrect URL
On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote: > The @jls and @jvms taglet share most of their functionality. A JLS URL > looks like > > https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1 > > and a JVMS URL looks like > > > https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2 > > The current taglet incorrectly uses "jls" in from the chapter for both JLS > and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4381
Re: RFR: 8268296: ScopedMemoryAccess build error with readonly filesystems
On Sun, 6 Jun 2021 20:09:32 GMT, Liam Miller-Cushon wrote: > This change fixes a build error during the generation of > `ScopedMemoryAccess.java` when the sources are readonly, by using `cat a > b` > instead of `cp a b` to avoid propagating the permissions to the generated > source. Looks good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4380
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
On Fri, 4 Jun 2021 20:55:51 GMT, Scott Gibbons wrote: > Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. > Also allows for performance improvement for non-AVX-512 enabled platforms. > Due to the nature of MIME-encoded inputs, modify the intrinsic signature to > accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide > the intrinsic information as to whether MIME decoding was being done. This > allows for the intrinsic to bypass the expensive setup of zmm registers from > AVX tables, knowing there may be invalid Base64 characters every 76 > characters or so. A change was also made here removing the restriction that > the intrinsic must return an even multiple of 3 bytes decoded. This > implementation handles the pad characters at the end of the string and will > return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop > iteration, then in chunks of 64 bytes, followed by end fixup decoding. The > non-AVX code is an assembly-optimized version of the java DecodeBlock and > behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance > by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers > are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using > this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 2 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26 The gitignore change looks ok, but should maybe be a separate change. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4368
Integrated: 8262891: Compiler implementation for Pattern Matching for switch (Preview)
On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for > switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common > superinterface for expressions and patterns, `CaseLabelTree`, which > expressions and patterns implement, and a list of case labels is returned > from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` > that represents it (`DefaultCaseLabelTree`). It is used also to represent the > conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be > disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, > String, enum) switches. This is a bit tricky for boxed primitives, as there > is no value that is not part of the input domain so that could be used to > represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It > produces code that delegates to a new bootstrap method, that will classify > the input value to the switch and return the case number, to which the switch > then jumps. To support guards, the switches (and the bootstrap method) are > restartable. The bootstrap method as such is written very simply so far, but > could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case > null: case String s:`/`case String s: case null:`, handling of these required > a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html This pull request has now been integrated. Changeset: 908aca29 Author:Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/908aca29ca60f5f251df8c6a31b2543929be12fc Stats: 4940 lines in 79 files changed: 4621 ins; 118 del; 201 mod 8262891: Compiler implementation for Pattern Matching for switch (Preview) Co-authored-by: Brian Goetz Co-authored-by: Mandy Chung Co-authored-by: Jan Lahoda Reviewed-by: mcimadamore, forax, godin, psandoz, mchung - PR: https://git.openjdk.java.net/jdk/pull/3863
