Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debuginfo and > compiler flags from generated .so files and fail with libsyslookup.so > > This simple patch adds a dummy function to `syslookup.c` so it appears more > like a regular file to be compiled. I can't see this causing a problem with > the symbol lookup, but we could filter it out on the Java side if need be. Ok, if it works, it's still going to be messy, as we have to disable this warning: - PR: https://git.openjdk.java.net/jdk/pull/6245
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v12]
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which fixes the issue reported in >> https://bugs.openjdk.java.net/browse/JDK-8275509? >> >> The `ModuleDescriptor.hashCode()` method uses the hash code of its various >> components to compute the final hash code. While doing so it ends up calling >> hashCode() on (collection of) various `enum` types. Since the hashCode() of >> enum types is generated from a call to `java.lang.Object.hashCode()`, their >> value isn't guaranteed to stay the same across multiple JVM runs. >> >> The commit here proposes to use the ordinal of the enum as the hash code. As >> Alan notes in the mailing list discussion, any changes to the ordinal of the >> enum (either due to addition of new value, removal of a value or just >> reordering existing values, all of which I think will be rare in these >> specific enum types) isn't expected to produce the same hash code across >> those changed runtimes and that should be okay. >> >> The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart >> from calls to the enum types hashCode(), rest of the calls in that >> implementation, either directly or indirectly end up as calls on >> `java.lang.String.hashCode()` and as such aren't expected to cause >> non-deterministic values. >> >> A new jtreg test has been added to reproduce this issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > use Enum#name() for hashCode() generation instead of Enum#ordinal() FWIW, the GitHub Actions job failure for Windows is due to an unrelated reason: 2021-11-04T05:22:48.5273779Z /usr/bin/bash: line 1: 1174 Segmentation fault (core dumped) /usr/bin/make -s -r -R -I /cygdrive/d/a/jdk/jdk/jdk/make/common SPEC=/cygdrive/d/a/jdk/jdk/jdk/build/windows-x64/spec.gmk MAKE_LOG_FLAGS="-s" -f ModuleWrapper.gmk -I /cygdrive/d/a/jdk/jdk/jdk/make/common/modules -I/cygdrive/d/a/jdk/jdk/jdk/make/modules/java.base MODULE=java.base MAKEFILE_PREFIX=Copy 2021-11-04T05:22:48.5304517Z make[2]: *** [make/Main.gmk:157: java.base-copy] Error 139 2021-11-04T05:22:48.5305851Z make[2]: *** Waiting for unfinished jobs 2021-11-04T05:22:48.8158343Z Compiling 12 properties into resource bundles for jdk.jdeps 2021-11-04T05:22:49.2707959Z 2021-11-04T05:22:49.2712144Z ERROR: Build failed for target 'default (product-bundles test-bundles)' in configuration 'windows-x64' (exit code 2) 2021-11-04T05:22:49.8818435Z 2021-11-04T05:22:49.8823500Z No indication of failed target found. 2021-11-04T05:22:49.8845292Z Hint: Try searching the build log for '] Error'. 2021-11-04T05:22:49.9156326Z Hint: See doc/building.html#troubleshooting for assistance. 2021-11-04T05:22:49.9156822Z 2021-11-04T05:22:49.9206739Z make[1]: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:315: main] Error 2 2021-11-04T05:22:49.9249924Z make: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:186: default] Error 2 2021-11-04T05:22:50.0054100Z ##[error]Process completed with exit code 1. Going ahead with the merge of this PR. Thank you Alan and Magnus for the inputs and the reviews. - PR: https://git.openjdk.java.net/jdk/pull/6078
Integrated: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds
On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various > components to compute the final hash code. While doing so it ends up calling > hashCode() on (collection of) various `enum` types. Since the hashCode() of > enum types is generated from a call to `java.lang.Object.hashCode()`, their > value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As > Alan notes in the mailing list discussion, any changes to the ordinal of the > enum (either due to addition of new value, removal of a value or just > reordering existing values, all of which I think will be rare in these > specific enum types) isn't expected to produce the same hash code across > those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart > from calls to the enum types hashCode(), rest of the calls in that > implementation, either directly or indirectly end up as calls on > `java.lang.String.hashCode()` and as such aren't expected to cause > non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. This pull request has now been integrated. Changeset: 396132ff Author:Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 Stats: 92 lines in 2 files changed: 88 ins; 0 del; 4 mod 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v12]
On Thu, 4 Nov 2021 14:08:50 GMT, Alan Bateman wrote: > One final thought on this is whether we should remove the > tools/jlink/JLinkReproducibleXXX tests from the exclude list. Yes, I'm working on it in a separate PR. - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v7]
On Wed, 3 Nov 2021 03:10:16 GMT, Ningsheng Jian wrote: > Converting from double to long and then narrow to target types did not follow > JLS. I will fix it. Thanks to @fg1417 for helping to find out this issue. Fixed in the new commit. Thanks to @PaulSandoz for integrating the fix! Hi Nick @nick-arm , Could you please help to review the new commit, which fixes the same issue as JDK-8276151 for SVE? Thanks! - PR: https://git.openjdk.java.net/jdk/pull/5873
Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v8]
On Thu, 4 Nov 2021 15:56:46 GMT, Paul Sandoz wrote: >> This PR improves the performance of vector operations that accept masks on >> architectures that support masking in hardware, specifically Intel AVX512 >> and ARM SVE. >> >> On architectures that do not support masking in hardware the same technique >> as before is applied to most operations, specifically composition using >> blend. >> >> Masked loads/stores are a special form of masked operation that require >> additional care to ensure out-of-bounds access throw exceptions. The range >> checking has not been fully optimized and will require further work. >> >> No API enhancements were required and only a few additional tests were >> needed. > > Paul Sandoz has updated the pull request incrementally with two additional > commits since the last revision: > > - Merge pull request #2 from nsjian/vector-conversion-fix > >AArch64: Incorrect SVE double to int and float to long vector conversion > - Incorrect double to int and float to long vector conversion > >Like JDK-8276151, SVE vector double to int and float to long >conversions have similar issue. According to Java language >specification [1], we should convert double/float to >integer/long directly, instead of converting to long/int and then >narrowing/extending to target types. Test cases will be updated in >JDK-8276151. > >[1] https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.3 Marked as reviewed by ngasson (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5873
Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
On Thu, 4 Nov 2021 12:40:15 GMT, Maurizio Cimadamore wrote: > Looks ok. As long as we don't introduce more dependencies. > > One question: would introducing a static function (so, not visible in the > resulting DLL) be good enough? I did wonder about this too. I'll have to check it still resolves the issues we see before updating the PR. - PR: https://git.openjdk.java.net/jdk/pull/6245
Re: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files
> (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
> ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
> - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
> - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
> - New openjdk build tool "GenerateZip" which produces the final
> determinsitic zip files as part of the build and also detects
> SOURCE_DATE_EPOCH
>
> Signed-off-by: Andrew Leonard
a few minor comments
make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 96:
> 94: ok = createOk;
> 95: }
> 96: out.close();
could be a try-with-resource block
make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 191:
> 189: Iterator> itr =
> filesToProcess.entrySet().iterator();
> 190: while(itr.hasNext()) {
> 191: Map.Entry entry = itr.next();
could be `for (Map.Entry entry : filesToProcess.entrySet())`
make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 262:
> 260: zos.write(buf, 0, len);
> 261: }
> 262: is.close();
try-with-resource candidate + in.transferTo(zos)
make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 291:
> 289: newArgs.add(arg);
> 290: }
> 291: return newArgs.toArray(new String[newArgs.size()]);
something might be missing here. It just adds args to a list and makes it an
array again + If the language level allows it toArray(String[]::new) could be
used.
src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 106:
> 104: value = -1;
> 105: }
> 106: return new Long(value);
value can be returned here directly which will use auto-boxing. (new Long(long)
is deprecated).
src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 799:
> 797: Iterator> itr =
> filesToProcess.entrySet().iterator();
> 798: while(itr.hasNext()) {
> 799: Map.Entry entry = itr.next();
another for-each candidate
test/jdk/java/util/zip/ZipSourceDateEpoch.java line 71:
> 69: zos.close();
> 70: os.close();
> 71: }
try-with-resource
test/jdk/java/util/zip/ZipSourceDateEpoch.java line 97:
> 95: zis.close();
> 96: fis.close();
> 97: }
try-with-resource
-
PR: https://git.openjdk.java.net/jdk/pull/6268
Re: RFR: 8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() [v3]
> This change optimizes random number generators using > Math.unsignedMultiplyHigh() Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: fix trailing whitespace - Changes: - all: https://git.openjdk.java.net/jdk/pull/6206/files - new: https://git.openjdk.java.net/jdk/pull/6206/files/e46c2d92..8bde4731 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6206=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6206=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6206/head:pull/6206 PR: https://git.openjdk.java.net/jdk/pull/6206
Re: RFR: 8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() [v2]
> This change optimizes random number generators using > Math.unsignedMultiplyHigh() Vamsi Parasa has updated the pull request incrementally with two additional commits since the last revision: - Fix year in copyright - micro benchmarks to test the performance - Changes: - all: https://git.openjdk.java.net/jdk/pull/6206/files - new: https://git.openjdk.java.net/jdk/pull/6206/files/c6ec6487..e46c2d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6206=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6206=00-01 Stats: 94 lines in 1 file changed: 94 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6206/head:pull/6206 PR: https://git.openjdk.java.net/jdk/pull/6206
Integrated: JDK-8276650: GenGraphs does not produce deterministic output
On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung wrote: > The dot graph should print the edges in alphatical order. A simple fix to > sort the edges before printing them. This pull request has now been integrated. Changeset: e21b5c7b Author:Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e Stats: 41 lines in 2 files changed: 2 ins; 1 del; 38 mod 8276650: GenGraphs does not produce deterministic output Reviewed-by: iris - PR: https://git.openjdk.java.net/jdk/pull/6266
Re: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
On Thu, 4 Nov 2021 21:51:46 GMT, Joe Darcy wrote: >> This PR enables reproducible Jars, Jmods and openjdk image zip files >> (eg.src.zip). >> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying >> ZipOutputStream's. >> It fixes the following keys issues relating to reproducibility: >> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware >> - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting >> - Jar and Jmod file content ordering was non-determinsitic >> - Fixes to Jar and Jmod main's to ensure sorted classes content ordering >> - openjdk image zip file generation used "zip" which is non-determinsitic >> - New openjdk build tool "GenerateZip" which produces the final >> determinsitic zip files as part of the build and also detects >> SOURCE_DATE_EPOCH >> >> Signed-off-by: Andrew Leonard > > Please file a CSR for the behavioral change of recognizing SOURCE_DATE_EPOCH, > etc. Thanks. @jddarcy CSR created: https://bugs.openjdk.java.net/browse/JDK-8276667 - PR: https://git.openjdk.java.net/jdk/pull/6268
Re: RFR: JDK-8276650: GenGraphs does not produce deterministic output
On Thu, 4 Nov 2021 21:46:21 GMT, Anthony Vanelverdinghe wrote: >> The dot graph should print the edges in alphatical order. A simple fix to >> sort the edges before printing them. > > src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336: > >> 334: private final String name; >> 335: private final Graph graph; >> 336: private final TreeSet descriptors = new >> TreeSet<>(); > > This change is unnecessary, isn't it? This will make it clear that this is sorted. - PR: https://git.openjdk.java.net/jdk/pull/6266
Re: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
On Thu, 4 Nov 2021 21:51:46 GMT, Joe Darcy wrote: >> This PR enables reproducible Jars, Jmods and openjdk image zip files >> (eg.src.zip). >> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying >> ZipOutputStream's. >> It fixes the following keys issues relating to reproducibility: >> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware >> - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting >> - Jar and Jmod file content ordering was non-determinsitic >> - Fixes to Jar and Jmod main's to ensure sorted classes content ordering >> - openjdk image zip file generation used "zip" which is non-determinsitic >> - New openjdk build tool "GenerateZip" which produces the final >> determinsitic zip files as part of the build and also detects >> SOURCE_DATE_EPOCH >> >> Signed-off-by: Andrew Leonard > > Please file a CSR for the behavioral change of recognizing SOURCE_DATE_EPOCH, > etc. Thanks. @jddarcy thanks, I did wonder that, i'll start a CSR, thanks - PR: https://git.openjdk.java.net/jdk/pull/6268
Re: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote: > This PR enables reproducible Jars, Jmods and openjdk image zip files > (eg.src.zip). > It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying > ZipOutputStream's. > It fixes the following keys issues relating to reproducibility: > - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware > - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting > - Jar and Jmod file content ordering was non-determinsitic > - Fixes to Jar and Jmod main's to ensure sorted classes content ordering > - openjdk image zip file generation used "zip" which is non-determinsitic > - New openjdk build tool "GenerateZip" which produces the final > determinsitic zip files as part of the build and also detects > SOURCE_DATE_EPOCH > > Signed-off-by: Andrew Leonard Please file a CSR for the behavioral change of recognizing SOURCE_DATE_EPOCH, etc. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/6268
Re: RFR: JDK-8276650: GenGraphs does not produce deterministic output
On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung wrote: > The dot graph should print the edges in alphatical order. A simple fix to > sort the edges before printing them. src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336: > 334: private final String name; > 335: private final Graph graph; > 336: private final TreeSet descriptors = new > TreeSet<>(); This change is unnecessary, isn't it? - PR: https://git.openjdk.java.net/jdk/pull/6266
Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
On Thu, 4 Nov 2021 20:12:52 GMT, Jiří Vaněk wrote: > Most likely bad idea, but isnt there an threat, that the method will be > dropped by optimising compiler? It is a possibility that the function will be dropped, but maybe worth a try. - PR: https://git.openjdk.java.net/jdk/pull/6245
Re: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote: > This PR enables reproducible Jars, Jmods and openjdk image zip files > (eg.src.zip). > It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying > ZipOutputStream's. > It fixes the following keys issues relating to reproducibility: > - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware > - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting > - Jar and Jmod file content ordering was non-determinsitic > - Fixes to Jar and Jmod main's to ensure sorted classes content ordering > - openjdk image zip file generation used "zip" which is non-determinsitic > - New openjdk build tool "GenerateZip" which produces the final > determinsitic zip files as part of the build and also detects > SOURCE_DATE_EPOCH > > Signed-off-by: Andrew Leonard @magicus fyi, please review if you have a moment, thanks - PR: https://git.openjdk.java.net/jdk/pull/6268
RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible
This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip). It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's. It fixes the following keys issues relating to reproducibility: - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting - Jar and Jmod file content ordering was non-determinsitic - Fixes to Jar and Jmod main's to ensure sorted classes content ordering - openjdk image zip file generation used "zip" which is non-determinsitic - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH Signed-off-by: Andrew Leonard - Commit messages: - 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible Changes: https://git.openjdk.java.net/jdk/pull/6268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6268=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276400 Stats: 818 lines in 11 files changed: 797 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/6268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6268/head:pull/6268 PR: https://git.openjdk.java.net/jdk/pull/6268
Integrated: JDK-8276653: Missing row headers in j.l.Character docs
On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk wrote: > The first table is missing row headers, adding them to aid screen readers. This pull request has now been integrated. Changeset: 8ec80c4b Author:Ludvig Janiuk Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod 8276653: Missing row headers in j.l.Character docs Reviewed-by: naoto - PR: https://git.openjdk.java.net/jdk/pull/6262
Re: RFR: JDK-8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list
On Thu, 4 Nov 2021 17:03:54 GMT, Mandy Chung wrote: >> Inferring from the flow of the text, the table should have been a list all >> along, so I've made it that way. Before and after for comparison: >>  >>  > > That's what I suspect related to accessibility. Thanks. @mlchung Could I ask you to sponsor this change? - PR: https://git.openjdk.java.net/jdk/pull/6260
Integrated: JDK-8276652: Missing row headers in MethodHandles.Lookup docs
On Thu, 4 Nov 2021 16:41:11 GMT, Ludvig Janiuk wrote: > Added row headers missing in the table captioned "Access mode summary". This > carries no visual change, but might be useful for screen readers. This pull request has now been integrated. Changeset: 7e87f946 Author:Ludvig Janiuk Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/7e87f946cedf93f19c38fd596039a16394c03ea4 Stats: 34 lines in 1 file changed: 0 ins; 0 del; 34 mod 8276652: Missing row headers in MethodHandles.Lookup docs Reviewed-by: mchung - PR: https://git.openjdk.java.net/jdk/pull/6261
Re: RFR: JDK-8276650: GenGraphs does not produce deterministic output
On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung wrote: > The dot graph should print the edges in alphatical order. A simple fix to > sort the edges before printing them. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6266
Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debuginfo and > compiler flags from generated .so files and fail with libsyslookup.so > > This simple patch adds a dummy function to `syslookup.c` so it appears more > like a regular file to be compiled. I can't see this causing a problem with > the symbol lookup, but we could filter it out on the Java side if need be. Most likely bad idea, but isnt there an threat, that the method will be dropped by optimising compiler? - PR: https://git.openjdk.java.net/jdk/pull/6245
Re: RFR: JDK-8276653: Missing row headers in j.l.Character docs
On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk wrote: > The first table is missing row headers, adding them to aid screen readers. LGTM. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6262
RFR: JDK-8276650: GenGraphs does not produce deterministic output
The dot graph should print the edges in alphatical order. A simple fix to sort the edges before printing them. - Commit messages: - JDK-8276650: GenGraphs does not produce deterministic output Changes: https://git.openjdk.java.net/jdk/pull/6266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6266=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276650 Stats: 41 lines in 2 files changed: 2 ins; 1 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/6266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6266/head:pull/6266 PR: https://git.openjdk.java.net/jdk/pull/6266
Integrated: JDK-8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote: > Inferring from the flow of the text, the table should have been a list all > along, so I've made it that way. Before and after for comparison: >  >  This pull request has now been integrated. Changeset: 99d4b07c Author:Ludvig Janiuk Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/99d4b07cddec05428e4d578ba6f494f51b92e841 Stats: 34 lines in 1 file changed: 0 ins; 20 del; 14 mod 8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list Reviewed-by: mchung - PR: https://git.openjdk.java.net/jdk/pull/6260
Re: RFR: 8276635: Use blessed modifier order in compiler code [v2]
> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts > verifies that modifiers are in the "blessed" order, and fixes it otherwise. I > have manually checked the changes made by the script to make sure they are > sound. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also update copyright year - Changes: - all: https://git.openjdk.java.net/jdk/pull/6253/files - new: https://git.openjdk.java.net/jdk/pull/6253/files/483213d3..b1e1b97f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6253=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6253=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6253.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6253/head:pull/6253 PR: https://git.openjdk.java.net/jdk/pull/6253
Re: RFR: JDK-8276652: Missing row headers in MethodHandles.Lookup docs
On Thu, 4 Nov 2021 16:41:11 GMT, Ludvig Janiuk wrote: > Added row headers missing in the table captioned "Access mode summary". This > carries no visual change, but might be useful for screen readers. Looks okay. Thanks for improving the documentation accessibility. - Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6261
Re: RFR: JDK-8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote: > Inferring from the flow of the text, the table should have been a list all > along, so I've made it that way. Before and after for comparison: >  >  It was flagged as an accessibility issue by a scanning tool. I don't think it's going to make a world of difference, but if the tool says it's better, I suppose why not change it. Also, just feels more natural. - PR: https://git.openjdk.java.net/jdk/pull/6260
Re: RFR: JDK-8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote: > Inferring from the flow of the text, the table should have been a list all > along, so I've made it that way. Before and after for comparison: >  >  Marked as reviewed by mchung (Reviewer). That's what I suspect related to accessibility. Thanks. BTW, I updated the summary of JBS issue. You will need to update this PR title to match it before integration. - PR: https://git.openjdk.java.net/jdk/pull/6260
Integrated: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. This pull request has now been integrated. Changeset: 1533b819 Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/1533b8191bed9d65ab4af03945584d8b2276d828 Stats: 44 lines in 28 files changed: 0 ins; 0 del; 44 mod 8276629: Use blessed modifier order in core-libs code Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris - PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6250
RFR: JDK-8276653: Missing row headers in j.l.Character docs
The first table is missing row headers, adding them to aid screen readers. - Commit messages: - Added row headers in Character docs Changes: https://git.openjdk.java.net/jdk/pull/6262/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6262=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276653 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/6262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6262/head:pull/6262 PR: https://git.openjdk.java.net/jdk/pull/6262
Re: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5]
On Wed, 3 Nov 2021 18:41:19 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains five commits: >> >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - Langtools command's usage were grabled on Japanese Windows > > Firstly, please do NOT rebase your fix, as it will clobber the review > history. Use merge instead. > As to the fix, I am not sure consolidating the code into Log.java would be OK > as it would introduce module dependency. @naotoj I'm sorry about my bad operation. @jonathan-gibbons I appreciate if you give me some suggestions. - PR: https://git.openjdk.java.net/jdk/pull/5771
Re: RFR: JDK-8276649: MethodHandles.Lookup docs: table could be list
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote: > Inferring from the flow of the text, the table should have been a list all > along, so I've made it that way. Before and after for comparison: >  >  Replacing this single-column table with a list is okay. Is there a reason why you want to make it a list? - PR: https://git.openjdk.java.net/jdk/pull/6260
RFR: JDK-8276652: Missing row headers in MethodHandles.Lookup docs
Added row headers missing in the table captioned "Access mode summary". This carries no visual change, but might be useful for screen readers. - Commit messages: - Added table headers Changes: https://git.openjdk.java.net/jdk/pull/6261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6261=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276652 Stats: 34 lines in 1 file changed: 0 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/6261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6261/head:pull/6261 PR: https://git.openjdk.java.net/jdk/pull/6261
Re: RFR: JDK-8275650 Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v5]
On Fri, 29 Oct 2021 10:38:41 GMT, Ivan Šipka wrote: >> cc @ctornqvi > > Ivan Šipka has updated the pull request incrementally with one additional > commit since the last revision: > > removed file added by accident I guess the proper course of actions would be not to mention any confidential comments/information (including their existence) in open communication at all, and instead provided open community with the enough publicly available information so they can understand the bug, patch, testing, …, in this particular case it would mean describing the testing w/o providing any details about oracle resources - PR: https://git.openjdk.java.net/jdk/pull/6025
Re: RFR: JDK-8275650 Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 [v5]
On Thu, 4 Nov 2021 02:14:09 GMT, Igor Ignatyev wrote:
>> Ivan Šipka has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> removed file added by accident
>
> Thanks for the clarification, David. I guess my recollection of jtreg code
> isn’t as good as I thought, and `-` isn’t mandatory, though this means there
> is a (theoretically possible) ambiguity, e.g. `{os=windows; version=11}` vs
> `{os=windows1; version=1}`
> @iignatev the comment is confidential as it refers to internal testing
> infrastructure. @frkator be mindful of what parts of the JBS issue are public
> and which are not.
@dholmes-ora you mean I should have stated that the links are in confidential
part of the ticket?
-
PR: https://git.openjdk.java.net/jdk/pull/6025
RFR: JDK-8276649: MethodHandles.Lookup docs: table could be list
Inferring from the flow of the text, the table should have been a list all along, so I've made it that way. Before and after for comparison:   - Commit messages: - Oops, trailing whitespace - Single column table -> list Changes: https://git.openjdk.java.net/jdk/pull/6260/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6260=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276649 Stats: 34 lines in 1 file changed: 0 ins; 20 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6260/head:pull/6260 PR: https://git.openjdk.java.net/jdk/pull/6260
RFR: 8276186: Require getAvailableLocales() methods to include Locale.ROOT
This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249 - Commit messages: - Minor fixup - Reflected CSR modifications - Added a test case - 8276186: Include Locale.ROOT in getAvailableLocales() methods Changes: https://git.openjdk.java.net/jdk/pull/6258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6258=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276186 Stats: 108 lines in 10 files changed: 86 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/6258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6258/head:pull/6258 PR: https://git.openjdk.java.net/jdk/pull/6258
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit
On Thu, 4 Nov 2021 13:10:37 GMT, Christian Stein wrote: > This PR implements the fix as suggested by Adam Farley, which reads: > >> Note: Looks to be as simple as adding `jaccessinspector-32` and >> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of >> `HelpFlagsTest.java`, as the non-32bit versions are already there. Looks fine to me. - Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6256
Re: RFR: 8271515: Integration of JEP 417: Vector API (Third Incubator) [v8]
> This PR improves the performance of vector operations that accept masks on > architectures that support masking in hardware, specifically Intel AVX512 and > ARM SVE. > > On architectures that do not support masking in hardware the same technique > as before is applied to most operations, specifically composition using blend. > > Masked loads/stores are a special form of masked operation that require > additional care to ensure out-of-bounds access throw exceptions. The range > checking has not been fully optimized and will require further work. > > No API enhancements were required and only a few additional tests were needed. Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #2 from nsjian/vector-conversion-fix AArch64: Incorrect SVE double to int and float to long vector conversion - Incorrect double to int and float to long vector conversion Like JDK-8276151, SVE vector double to int and float to long conversions have similar issue. According to Java language specification [1], we should convert double/float to integer/long directly, instead of converting to long/int and then narrowing/extending to target types. Test cases will be updated in JDK-8276151. [1] https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.3 - Changes: - all: https://git.openjdk.java.net/jdk/pull/5873/files - new: https://git.openjdk.java.net/jdk/pull/5873/files/c9a77225..571e6f39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5873=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5873=06-07 Stats: 40 lines in 2 files changed: 22 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5873/head:pull/5873 PR: https://git.openjdk.java.net/jdk/pull/5873
Integrated: 8276338: Minor improve of wording for String.to(Lower|Upper)Case
On Wed, 3 Nov 2021 11:58:42 GMT, Pavel Rappo wrote: > This PR fixes two sentences which conflate a string with its length, and also > makes the "equivalency wording" consistent. > > There are many ways to fix "the resulting String may be a different length > than the original String". The proposed way might be one of the most > lightweight ways to do that. This pull request has now been integrated. Changeset: bf4ddf9c Author:Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/bf4ddf9cb7408db321e7fd73600a5a9a85ca49eb Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod 8276338: Minor improve of wording for String.to(Lower|Upper)Case Reviewed-by: rriggs, naoto - PR: https://git.openjdk.java.net/jdk/pull/6232
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v12]
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which fixes the issue reported in >> https://bugs.openjdk.java.net/browse/JDK-8275509? >> >> The `ModuleDescriptor.hashCode()` method uses the hash code of its various >> components to compute the final hash code. While doing so it ends up calling >> hashCode() on (collection of) various `enum` types. Since the hashCode() of >> enum types is generated from a call to `java.lang.Object.hashCode()`, their >> value isn't guaranteed to stay the same across multiple JVM runs. >> >> The commit here proposes to use the ordinal of the enum as the hash code. As >> Alan notes in the mailing list discussion, any changes to the ordinal of the >> enum (either due to addition of new value, removal of a value or just >> reordering existing values, all of which I think will be rare in these >> specific enum types) isn't expected to produce the same hash code across >> those changed runtimes and that should be okay. >> >> The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart >> from calls to the enum types hashCode(), rest of the calls in that >> implementation, either directly or indirectly end up as calls on >> `java.lang.String.hashCode()` and as such aren't expected to cause >> non-deterministic values. >> >> A new jtreg test has been added to reproduce this issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > use Enum#name() for hashCode() generation instead of Enum#ordinal() Marked as reviewed by ihse (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v12]
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which fixes the issue reported in >> https://bugs.openjdk.java.net/browse/JDK-8275509? >> >> The `ModuleDescriptor.hashCode()` method uses the hash code of its various >> components to compute the final hash code. While doing so it ends up calling >> hashCode() on (collection of) various `enum` types. Since the hashCode() of >> enum types is generated from a call to `java.lang.Object.hashCode()`, their >> value isn't guaranteed to stay the same across multiple JVM runs. >> >> The commit here proposes to use the ordinal of the enum as the hash code. As >> Alan notes in the mailing list discussion, any changes to the ordinal of the >> enum (either due to addition of new value, removal of a value or just >> reordering existing values, all of which I think will be rare in these >> specific enum types) isn't expected to produce the same hash code across >> those changed runtimes and that should be okay. >> >> The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart >> from calls to the enum types hashCode(), rest of the calls in that >> implementation, either directly or indirectly end up as calls on >> `java.lang.String.hashCode()` and as such aren't expected to cause >> non-deterministic values. >> >> A new jtreg test has been added to reproduce this issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > use Enum#name() for hashCode() generation instead of Enum#ordinal() One final thought on this is whether we should remove the tools/jlink/JLinkReproducibleXXX tests from the exclude list. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds
On Thu, 4 Nov 2021 05:21:25 GMT, Jaikiran Pai wrote: > That's a good point and thank you for explaining that part. So to address > that, how about not leaving them out, but instead of using `Enum#ordinal()` > for the hashCode generation, we use `Enum#name()` which would translate to a > `String#hashCode()`. Moving to the hashCode of the names of the values is good. - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8276338: Minor improve of wording for String.to(Lower|Upper)Case [v2]
On Thu, 4 Nov 2021 13:54:37 GMT, Pavel Rappo wrote: >> This PR fixes two sentences which conflate a string with its length, and >> also makes the "equivalency wording" consistent. >> >> There are many ways to fix "the resulting String may be a different length >> than the original String". The proposed way might be one of the most >> lightweight ways to do that. > > Pavel Rappo has updated the pull request incrementally with one additional > commit since the last revision: > > Fix inconsistent formatting > >- Removes stray whitespace character *inside* a sentence. >- Makes sentences that introduce tables more similar. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6232
Re: RFR: 8276338: Minor improve of wording for String.to(Lower|Upper)Case [v2]
> This PR fixes two sentences which conflate a string with its length, and also > makes the "equivalency wording" consistent. > > There are many ways to fix "the resulting String may be a different length > than the original String". The proposed way might be one of the most > lightweight ways to do that. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Fix inconsistent formatting - Removes stray whitespace character *inside* a sentence. - Makes sentences that introduce tables more similar. - Changes: - all: https://git.openjdk.java.net/jdk/pull/6232/files - new: https://git.openjdk.java.net/jdk/pull/6232/files/897ac5bb..625ae1aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6232=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6232=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6232/head:pull/6232 PR: https://git.openjdk.java.net/jdk/pull/6232
RFR: 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit
This PR implements the fix as suggested by Adam Farley, which reads: > Note: Looks to be as simple as adding `jaccessinspector-32` and > `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of `HelpFlagsTest.java`, > as the non-32bit versions are already there. - Commit messages: - Ignore `jaccessinspector-32` and `jaccesswalker-32` Changes: https://git.openjdk.java.net/jdk/pull/6256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6256=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273235 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6256/head:pull/6256 PR: https://git.openjdk.java.net/jdk/pull/6256
Re: RFR: 8276635: Use blessed modifier order in compiler code
On Thu, 4 Nov 2021 11:48:04 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts > verifies that modifiers are in the "blessed" order, and fixes it otherwise. I > have manually checked the changes made by the script to make sure they are > sound. Looks fine. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6253
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 12:30:40 GMT, Aleksei Efimov wrote: >> I can see that this PR changes java.naming. Another bug to change >> java.naming, JDK-8276552, was filed yesterday. Please check with its >> reporter and coordinate this effort if necessary. > >> I can see that this PR changes java.naming. Another bug to change >> java.naming, JDK-8276552, was filed yesterday. Please check with its >> reporter and coordinate this effort if necessary. > > @magicus I'm ok with having `java.naming` changes integrated as part of this > PR. I'll close `JDK-8276552` as duplicate. > The changes looks fine to me. @AlekseiEfimov Thanks! I tried to search for open PRs with blessed ordering, but I did not search open bugs... - PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debuginfo and > compiler flags from generated .so files and fail with libsyslookup.so > > This simple patch adds a dummy function to `syslookup.c` so it appears more > like a regular file to be compiled. I can't see this causing a problem with > the symbol lookup, but we could filter it out on the Java side if need be. Looks ok. As long as we don't introduce more dependencies. One question: would introducing a static function (so, not visible in the resulting DLL) be good enough? - Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6245
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:31:50 GMT, Pavel Rappo wrote: > I can see that this PR changes java.naming. Another bug to change > java.naming, JDK-8276552, was filed yesterday. Please check with its reporter > and coordinate this effort if necessary. @magicus I'm ok with having `java.naming` changes integrated as part of this PR. I'll close `JDK-8276552` as duplicate. The changes looks fine to me. - PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. Marked as reviewed by aefimov (Committer). - PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. Looks fine to me. Thanks, David - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6250
RFR: 8276635: Use blessed modifier order in compiler code
I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. - Commit messages: - 8276635: Use blessed modifier order in compiler code Changes: https://git.openjdk.java.net/jdk/pull/6253/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6253=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276635 Stats: 45 lines in 24 files changed: 0 ins; 0 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/6253.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6253/head:pull/6253 PR: https://git.openjdk.java.net/jdk/pull/6253
Re: RFR: 8276629: Use blessed modifier order in core-libs code
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by core-libs. This > scripts verifies that modifiers are in the "blessed" order, and fixes it > otherwise. I have manually checked the changes made by the script to make > sure they are sound. I can see that this PR changes java.naming. Another bug to change java.naming, JDK-8276552, was filed yesterday. Please check with its reporter and coordinate this effort if necessary. - PR: https://git.openjdk.java.net/jdk/pull/6250
RFR: 8276629: Use blessed modifier order in core-libs code
I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. - Commit messages: - 8276629: Use blessed modifier order in core-libs code Changes: https://git.openjdk.java.net/jdk/pull/6250/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6250=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276629 Stats: 44 lines in 28 files changed: 0 ins; 0 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/6250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6250/head:pull/6250 PR: https://git.openjdk.java.net/jdk/pull/6250
Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debuginfo and > compiler flags from generated .so files and fail with libsyslookup.so > > This simple patch adds a dummy function to `syslookup.c` so it appears more > like a regular file to be compiled. I can't see this causing a problem with > the symbol lookup, but we could filter it out on the Java side if need be. This makes sense to me, but @mcimadamore should ack this. - PR: https://git.openjdk.java.net/jdk/pull/6245
Integrated: 8276217: Harmonize StrictMath intrinsics handling
On Mon, 1 Nov 2021 11:23:16 GMT, Aleksey Shipilev wrote: > This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by > giving failing intrinsics a second chance to match against the similar `Math` > intrinsics. This has interesting consequence for matchers: we can match the > native `StrictMath.sqrt` to non-native intrinsic for `Math.sqrt`. Interpreter > would then have to disambiguate the two. It could be made simpler and more > consistent. > > For `min`/`max` methods, `StrictMath` already delegates to `Math` methods, so > we can just drop the intrinsics for them. `sqrt` is harder to delegate, > because it is `native` and a part of public API, so we can instead do the > proper special intrinsic for it. > > There seem to be no performance regressions with this patch at least on Linux > x86_64: > > > $ CONF=linux-x86_64-server-release make test TEST="micro:StrictMathBench" > > Benchmark Mode Cnt Score Error Units > > ### Before > > StrictMathBench.minDouble thrpt4 230921.558 ± 234.238 ops/ms > StrictMathBench.minFloat thrpt4 230932.303 ± 126.721 ops/ms > StrictMathBench.minInt thrpt4 230917.256 ± 73.008 ops/ms > StrictMathBench.minLongthrpt4 194460.828 ± 178.079 ops/ms > > > StrictMathBench.maxDouble thrpt4 230983.180 ± 161.211 ops/ms > StrictMathBench.maxFloat thrpt4 230969.290 ± 277.500 ops/ms > StrictMathBench.maxInt thrpt4 231033.581 ± 200.015 ops/ms > StrictMathBench.maxLongthrpt4 194590.744 ± 114.295 ops/ms > > > StrictMathBench.sqrtDouble thrpt4 230722.037 ± .080 ops/ms > > ### After > > StrictMathBench.minDouble thrpt4 230976.625 ± 67.338 ops/ms > StrictMathBench.minFloat thrpt4 230896.021 ± 270.434 ops/ms > StrictMathBench.minInt thrpt4 230859.741 ± 403.147 ops/ms > StrictMathBench.minLongthrpt4 194456.673 ± 111.557 ops/ms > > StrictMathBench.maxDouble thrpt4 230890.776 ± 89.924 ops/ms > StrictMathBench.maxFloat thrpt4 230918.334 ± 63.160 ops/ms > StrictMathBench.maxInt thrpt4 231059.128 ± 51.224 ops/ms > StrictMathBench.maxLongthrpt4 194488.210 ± 495.224 ops/ms > > StrictMathBench.sqrtDouble thrpt4 231023.703 ± 247.330 ops/ms > > > Additional testing: > - [x] `StrictMath` benchmarks > - [x] Linux x86_64 fastdebug `java/lang/StrictMath`, `java/lang/Math` > - [x] Linux x86_64 fastdebug `tier1` This pull request has now been integrated. Changeset: 9eadcbb4 Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9eadcbb47e902f42d933ba68e24f2bfb0ee20915 Stats: 125 lines in 15 files changed: 80 ins; 27 del; 18 mod 8276217: Harmonize StrictMath intrinsics handling Reviewed-by: aph, kvn - PR: https://git.openjdk.java.net/jdk/pull/6184
Integrated: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe` interface by falling back to `fullFence` when `{load|store}Fence`
> intrinsics are not available. This would be similar to what
> `Unsafe.{loadLoad|storeStore}Fences` do.
>
> This is the behavior of these intrinsics now, on x86_64, using benchmarks
> from JDK-8276054:
>
>
> Benchmark Mode Cnt Score Error Units
>
> # Default
> Single.acquire avgt3 0.407 ± 0.060 ns/op
> Single.fullavgt3 4.693 ± 0.005 ns/op
> Single.loadLoadavgt3 0.415 ± 0.095 ns/op
> Single.plain avgt3 0.406 ± 0.002 ns/op
> Single.release avgt3 0.408 ± 0.047 ns/op
> Single.storeStore avgt3 0.408 ± 0.043 ns/op
>
> # -XX:DisableIntrinsic=_storeFence
> Single.acquire avgt3 0.408 ± 0.016 ns/op
> Single.fullavgt3 4.694 ± 0.002 ns/op
> Single.loadLoadavgt3 0.406 ± 0.002 ns/op
> Single.plain avgt3 0.406 ± 0.001 ns/op
> Single.release avgt3 4.694 ± 0.003 ns/op <--- upgraded to full
> Single.storeStore avgt3 4.690 ± 0.005 ns/op <--- upgraded to full
>
> # -XX:DisableIntrinsic=_loadFence
> Single.acquire avgt3 4.691 ± 0.001 ns/op <--- upgraded to full
> Single.fullavgt3 4.693 ± 0.009 ns/op
> Single.loadLoadavgt3 4.693 ± 0.013 ns/op <--- upgraded to full
> Single.plain avgt3 0.408 ± 0.072 ns/op
> Single.release avgt3 0.415 ± 0.016 ns/op
> Single.storeStore avgt3 0.416 ± 0.041 ns/op
>
> # -XX:DisableIntrinsic=_fullFence
> Single.acquire avgt3 0.406 ± 0.014 ns/op
> Single.fullavgt3 15.836 ± 0.151 ns/op <--- calls runtime
> Single.loadLoadavgt3 0.406 ± 0.001 ns/op
> Single.plain avgt3 0.426 ± 0.361 ns/op
> Single.release avgt3 0.407 ± 0.021 ns/op
> Single.storeStore avgt3 0.410 ± 0.061 ns/op
>
> # -XX:DisableIntrinsic=_fullFence,_loadFence
> Single.acquire avgt3 15.822 ± 0.282 ns/op <--- upgraded, calls
> runtime
> Single.fullavgt3 15.851 ± 0.127 ns/op <--- calls runtime
> Single.loadLoadavgt3 15.829 ± 0.045 ns/op <--- upgraded, calls
> runtime
> Single.plain avgt3 0.406 ± 0.001 ns/op
> Single.release avgt3 0.414 ± 0.156 ns/op
> Single.storeStore avgt3 0.422 ± 0.452 ns/op
>
> # -XX:DisableIntrinsic=_fullFence,_storeFence
> Single.acquire avgt3 0.407 ± 0.016 ns/op
> Single.fullavgt3 15.347 ± 6.783 ns/op <--- calls runtime
> Single.loadLoadavgt3 0.406 ± 0.001 ns/op
> Single.plain avgt3 0.406 ± 0.002 ns/op
> Single.release avgt3 15.828 ± 0.019 ns/op <--- upgraded, calls
> runtime
> Single.storeStore avgt3 15.834 ± 0.045 ns/op <--- upgraded, calls
> runtime
>
> # -XX:DisableIntrinsic=_fullFence,_loadFence,_storeFence
> Single.acquire avgt3 15.838 ± 0.030 ns/op <--- upgraded, calls
> runtime
> Single.fullavgt3 15.854 ± 0.277 ns/op <--- calls runtime
> Single.loadLoadavgt3 15.826 ± 0.160 ns/op <--- upgraded, calls
> runtime
> Single.plain avgt3 0.406 ± 0.003 ns/op
> Single.release avgt3 15.838 ± 0.019 ns/op <--- upgraded, calls
> runtime
> Single.storeStore avgt3 15.844 ± 0.104 ns/op <--- upgraded, calls
> runtime
>
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `tier1`
This pull request has now been integrated.
Changeset: fb0be81f
Author:Aleksey Shipilev
URL:
https://git.openjdk.java.net/jdk/commit/fb0be81f0148d9aea73321a0c2bd83b2e477d952
Stats: 21 lines in 3 files changed: 6 ins; 11 del; 4 mod
8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence
Reviewed-by: psandoz, aph, dholmes
-
PR: https://git.openjdk.java.net/jdk/pull/6149
Re: RFR: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence [v2]
On Mon, 1 Nov 2021 07:36:53 GMT, Aleksey Shipilev wrote:
>> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
>> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed
>> (useless?) to call to runtime for a single memory barrier. We can simplify
>> the native `Unsafe` interface by falling back to `fullFence` when
>> `{load|store}Fence` intrinsics are not available. This would be similar to
>> what `Unsafe.{loadLoad|storeStore}Fences` do.
>>
>> This is the behavior of these intrinsics now, on x86_64, using benchmarks
>> from JDK-8276054:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>>
>> # Default
>> Single.acquire avgt3 0.407 ± 0.060 ns/op
>> Single.fullavgt3 4.693 ± 0.005 ns/op
>> Single.loadLoadavgt3 0.415 ± 0.095 ns/op
>> Single.plain avgt3 0.406 ± 0.002 ns/op
>> Single.release avgt3 0.408 ± 0.047 ns/op
>> Single.storeStore avgt3 0.408 ± 0.043 ns/op
>>
>> # -XX:DisableIntrinsic=_storeFence
>> Single.acquire avgt3 0.408 ± 0.016 ns/op
>> Single.fullavgt3 4.694 ± 0.002 ns/op
>> Single.loadLoadavgt3 0.406 ± 0.002 ns/op
>> Single.plain avgt3 0.406 ± 0.001 ns/op
>> Single.release avgt3 4.694 ± 0.003 ns/op <--- upgraded to full
>> Single.storeStore avgt3 4.690 ± 0.005 ns/op <--- upgraded to full
>>
>> # -XX:DisableIntrinsic=_loadFence
>> Single.acquire avgt3 4.691 ± 0.001 ns/op <--- upgraded to full
>> Single.fullavgt3 4.693 ± 0.009 ns/op
>> Single.loadLoadavgt3 4.693 ± 0.013 ns/op <--- upgraded to full
>> Single.plain avgt3 0.408 ± 0.072 ns/op
>> Single.release avgt3 0.415 ± 0.016 ns/op
>> Single.storeStore avgt3 0.416 ± 0.041 ns/op
>>
>> # -XX:DisableIntrinsic=_fullFence
>> Single.acquire avgt3 0.406 ± 0.014 ns/op
>> Single.fullavgt3 15.836 ± 0.151 ns/op <--- calls runtime
>> Single.loadLoadavgt3 0.406 ± 0.001 ns/op
>> Single.plain avgt3 0.426 ± 0.361 ns/op
>> Single.release avgt3 0.407 ± 0.021 ns/op
>> Single.storeStore avgt3 0.410 ± 0.061 ns/op
>>
>> # -XX:DisableIntrinsic=_fullFence,_loadFence
>> Single.acquire avgt3 15.822 ± 0.282 ns/op <--- upgraded, calls
>> runtime
>> Single.fullavgt3 15.851 ± 0.127 ns/op <--- calls runtime
>> Single.loadLoadavgt3 15.829 ± 0.045 ns/op <--- upgraded, calls
>> runtime
>> Single.plain avgt3 0.406 ± 0.001 ns/op
>> Single.release avgt3 0.414 ± 0.156 ns/op
>> Single.storeStore avgt3 0.422 ± 0.452 ns/op
>>
>> # -XX:DisableIntrinsic=_fullFence,_storeFence
>> Single.acquire avgt3 0.407 ± 0.016 ns/op
>> Single.fullavgt3 15.347 ± 6.783 ns/op <--- calls runtime
>> Single.loadLoadavgt3 0.406 ± 0.001 ns/op
>> Single.plain avgt3 0.406 ± 0.002 ns/op
>> Single.release avgt3 15.828 ± 0.019 ns/op <--- upgraded, calls
>> runtime
>> Single.storeStore avgt3 15.834 ± 0.045 ns/op <--- upgraded, calls
>> runtime
>>
>> # -XX:DisableIntrinsic=_fullFence,_loadFence,_storeFence
>> Single.acquire avgt3 15.838 ± 0.030 ns/op <--- upgraded, calls
>> runtime
>> Single.fullavgt3 15.854 ± 0.277 ns/op <--- calls runtime
>> Single.loadLoadavgt3 15.826 ± 0.160 ns/op <--- upgraded, calls
>> runtime
>> Single.plain avgt3 0.406 ± 0.003 ns/op
>> Single.release avgt3 15.838 ± 0.019 ns/op <--- upgraded, calls
>> runtime
>> Single.storeStore avgt3 15.844 ± 0.104 ns/op <--- upgraded, calls
>> runtime
>>
>>
>> Additional testing:
>> - [x] Linux x86_64 fastdebug `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Restore RN for fullFence
Thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/6149
Re: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java
Hi There, Hotspot developers already identified a bug in verification (failure to capture an invalid package name "die/verwandlung/" existing in the constant pool of bytecode) at https://bugs.openjdk.java.net/browse/JDK-8276241 as I raised via https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-October/055618.html , which was associated with the issue here in XSLT transformation given the invalid package name "die/verwandlung/" was actually triggered by OpenJDK due to the incorrect result from setClassName(Util.baseName(systemId)) (systemId = "xxx:" in which case Util.baseName(systemId) returns null and setClassName(null) ended up with "die/verwandlung/" in generating the bytecode). So I expect someone in OpenJDK to take a look into this issue to see what really happened to the code there in such case. Thanks. Thanks and Best Regards Cheng Jin
