November 2021 - core-libs-dev

RFR: 8276338: Minor improve of wording for String.to(Lower|Upper)Case
by Pavel Rappo 04 Nov '21

04 Nov '21

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. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6232/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276338 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 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

3 5

RFR: 8276217: Harmonize StrictMath intrinsics handling
by Aleksey Shipilev 04 Nov '21

04 Nov '21

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 thrpt 4 230921.558 ± 234.238 ops/ms StrictMathBench.minFloat thrpt 4 230932.303 ± 126.721 ops/ms StrictMathBench.minInt thrpt 4 230917.256 ± 73.008 ops/ms StrictMathBench.minLong thrpt 4 194460.828 ± 178.079 ops/ms StrictMathBench.maxDouble thrpt 4 230983.180 ± 161.211 ops/ms StrictMathBench.maxFloat thrpt 4 230969.290 ± 277.500 ops/ms StrictMathBench.maxInt thrpt 4 231033.581 ± 200.015 ops/ms StrictMathBench.maxLong thrpt 4 194590.744 ± 114.295 ops/ms StrictMathBench.sqrtDouble thrpt 4 230722.037 ± 2222.080 ops/ms ### After StrictMathBench.minDouble thrpt 4 230976.625 ± 67.338 ops/ms StrictMathBench.minFloat thrpt 4 230896.021 ± 270.434 ops/ms StrictMathBench.minInt thrpt 4 230859.741 ± 403.147 ops/ms StrictMathBench.minLong thrpt 4 194456.673 ± 111.557 ops/ms StrictMathBench.maxDouble thrpt 4 230890.776 ± 89.924 ops/ms StrictMathBench.maxFloat thrpt 4 230918.334 ± 63.160 ops/ms StrictMathBench.maxInt thrpt 4 231059.128 ± 51.224 ops/ms StrictMathBench.maxLong thrpt 4 194488.210 ± 495.224 ops/ms StrictMathBench.sqrtDouble thrpt 4 231023.703 ± 247.330 ops/ms Additional testing: - [x] `StrictMath` benchmarks - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276217 Stats: 66 lines in 16 files changed: 27 ins; 26 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6184/head:pull/6184 PR: https://git.openjdk.java.net/jdk/pull/6184

3 13

RFR: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence
by Aleksey Shipilev 04 Nov '21

04 Nov '21

`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 avgt 3 0.407 ± 0.060 ns/op Single.full avgt 3 4.693 ± 0.005 ns/op Single.loadLoad avgt 3 0.415 ± 0.095 ns/op Single.plain avgt 3 0.406 ± 0.002 ns/op Single.release avgt 3 0.408 ± 0.047 ns/op Single.storeStore avgt 3 0.408 ± 0.043 ns/op # -XX:DisableIntrinsic=_storeFence Single.acquire avgt 3 0.408 ± 0.016 ns/op Single.full avgt 3 4.694 ± 0.002 ns/op Single.loadLoad avgt 3 0.406 ± 0.002 ns/op Single.plain avgt 3 0.406 ± 0.001 ns/op Single.release avgt 3 4.694 ± 0.003 ns/op <--- upgraded to full Single.storeStore avgt 3 4.690 ± 0.005 ns/op <--- upgraded to full # -XX:DisableIntrinsic=_loadFence Single.acquire avgt 3 4.691 ± 0.001 ns/op <--- upgraded to full Single.full avgt 3 4.693 ± 0.009 ns/op Single.loadLoad avgt 3 4.693 ± 0.013 ns/op <--- upgraded to full Single.plain avgt 3 0.408 ± 0.072 ns/op Single.release avgt 3 0.415 ± 0.016 ns/op Single.storeStore avgt 3 0.416 ± 0.041 ns/op # -XX:DisableIntrinsic=_fullFence Single.acquire avgt 3 0.406 ± 0.014 ns/op Single.full avgt 3 15.836 ± 0.151 ns/op <--- calls runtime Single.loadLoad avgt 3 0.406 ± 0.001 ns/op Single.plain avgt 3 0.426 ± 0.361 ns/op Single.release avgt 3 0.407 ± 0.021 ns/op Single.storeStore avgt 3 0.410 ± 0.061 ns/op # -XX:DisableIntrinsic=_fullFence,_loadFence Single.acquire avgt 3 15.822 ± 0.282 ns/op <--- upgraded, calls runtime Single.full avgt 3 15.851 ± 0.127 ns/op <--- calls runtime Single.loadLoad avgt 3 15.829 ± 0.045 ns/op <--- upgraded, calls runtime Single.plain avgt 3 0.406 ± 0.001 ns/op Single.release avgt 3 0.414 ± 0.156 ns/op Single.storeStore avgt 3 0.422 ± 0.452 ns/op # -XX:DisableIntrinsic=_fullFence,_storeFence Single.acquire avgt 3 0.407 ± 0.016 ns/op Single.full avgt 3 15.347 ± 6.783 ns/op <--- calls runtime Single.loadLoad avgt 3 0.406 ± 0.001 ns/op Single.plain avgt 3 0.406 ± 0.002 ns/op Single.release avgt 3 15.828 ± 0.019 ns/op <--- upgraded, calls runtime Single.storeStore avgt 3 15.834 ± 0.045 ns/op <--- upgraded, calls runtime # -XX:DisableIntrinsic=_fullFence,_loadFence,_storeFence Single.acquire avgt 3 15.838 ± 0.030 ns/op <--- upgraded, calls runtime Single.full avgt 3 15.854 ± 0.277 ns/op <--- calls runtime Single.loadLoad avgt 3 15.826 ± 0.160 ns/op <--- upgraded, calls runtime Single.plain avgt 3 0.406 ± 0.003 ns/op Single.release avgt 3 15.838 ± 0.019 ns/op <--- upgraded, calls runtime Single.storeStore avgt 3 15.844 ± 0.104 ns/op <--- upgraded, calls runtime Additional testing: - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276096 Stats: 22 lines in 3 files changed: 6 ins; 11 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6149/head:pull/6149 PR: https://git.openjdk.java.net/jdk/pull/6149

4 11

RFR: 8276348: Use blessed modifier order in java.base
by Pavel Rappo 04 Nov '21

04 Nov '21

This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: $ sh ./bin/blessed-modifier-order.sh src/java.base The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.… (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.… ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6213/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6213&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276348 Stats: 39 lines in 21 files changed: 0 ins; 0 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/6213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6213/head:pull/6213 PR: https://git.openjdk.java.net/jdk/pull/6213

11 23

Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java
by Cheng Jin 03 Nov '21

03 Nov '21

Hi there, The code in compile(InputSource input, String name) at https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/s… seems incorrect as follows: public boolean compile(InputSource input, String name) { try { // Reset globals in case we're called by compile(ArrayList v); reset(); // The systemId may not be set, so we'll have to check the URL String systemId = null; if (input != null) { systemId = input.getSystemId(); } // Set the translet class name if not already set if (_className == null) { if (name != null) { setClassName(name); } else if (systemId != null && !systemId.equals("")) { setClassName(Util.baseName(systemId)); <------- incorrect here } // Ensure we have a non-empty class name at this point if (_className == null || _className.length() == 0) { setClassName("GregorSamsa"); // default translet name } } ... Specifically, the code above assumes that systemId is something like "xxx:yyy" in which case the class name (_className) is "die.verwandlung.yyy" ("die.verwandlung." is the default package name since Java11) However,Util.baseName(systemId) returns null when systemId is something like "xxx:" (empty after ":"), in which case the class name (_className) ends up with "die.verwandlung."(an invalid class name inserted in the constant pool of the generated bytecode). >From the perspective of robustness, the code above should be updated to handle the situation. e.g. else if (systemId != null && !systemId.equals("")) { String baseName = Util.baseName(systemId); if ((baseName != null) && (baseName.length() > 0)) { <------ setClassName(baseName); } which means it should check whether the returned base name from Util.baseName(systemId) is empty before setting the class name; otherwise, it should use the default class name ("GregorSamsa"). Let me know if any other concern on this fix. Thanks and Best Regards Cheng Jin

1 3

RFR #8275063
by SyaifulNizam Shamsudin 03 Nov '21

03 Nov '21

Update this core file-- null

1 0

Active file
by SyaifulNizam Shamsudin 03 Nov '21

03 Nov '21

Submit this core file-- null

1 0

8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters
by Anirvan Sarkar 02 Nov '21

02 Nov '21

Hi, Properties.loadFromXML/storeToXML works incorrectly for supplementary characters after JDK-8042889[1] was integrated in JDK 9. Properties.storeToXML now generates incorrect character references for supplementary characters. This is similar to JDK-8145974[2] which was fixed in the java.xml module in JDK 9. Properties.loadFromXML now fails to parse character references for supplementary characters and throws InvalidPropertiesFormatException. Sample program which demonstrates these issues is in the JBS[3]. Proposed patch to fix this issue is attached. JDK Tier 1 tests are all green. If it looks fine then I will create a pull request based on this. [1] : https://bugs.openjdk.java.net/browse/JDK-8042889 [2] : https://bugs.openjdk.java.net/browse/JDK-8145974 [3] : https://bugs.openjdk.java.net/browse/JDK-8276207 -- Anirvan

2 3

RFR: 8276188: Clarify "default charset" descriptions in String class
by Naoto Sato 02 Nov '21

02 Nov '21

This is a leftover document fix to `String` class for the JEP 400. Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276238 ------------- Commit messages: - 8276188: Clarify "default charset" descriptions in String class Changes: https://git.openjdk.java.net/jdk/pull/6198/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6198&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276188 Stats: 16 lines in 1 file changed: 2 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/6198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6198/head:pull/6198 PR: https://git.openjdk.java.net/jdk/pull/6198

3 3

New candidate JEP: 421: Deprecate Finalization for Removal
by mark.reinhold＠oracle.com 02 Nov '21

02 Nov '21

https://openjdk.java.net/jeps/421 Summary: Deprecate finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled to facilitate early testing. In a future release it will be disabled by default, and in a later release it will be removed. Maintainers of libraries and applications that rely upon finalization should consider migrating to other resource management techniques such as the try-with-resources statement and cleaners. - Mark

3 3