October 2021 - core-libs-dev

RFR: 8252990: Intrinsify Unsafe.storeStoreFence
by Aleksey Shipilev 02 Nov '21

02 Nov '21

`Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`. We can teach compilers to map this directly to already existing rules that handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce the special node to differentiate explicit fence and implicit store-store barriers. This node is usually used to simulate safe `final`-field like constructions in special JDK classes, like `ConstantCallSite` and friends. Motivational performance difference on benchmarks from JDK-8276054 on ARM32: Benchmark Mode Cnt Score Error Units Multiple.plain avgt 3 2.669 ± 0.004 ns/op Multiple.release avgt 3 16.688 ± 0.057 ns/op Multiple.storeStore avgt 3 14.021 ± 0.144 ns/op // Better MultipleWithLoads.plain avgt 3 4.672 ± 0.053 ns/op MultipleWithLoads.release avgt 3 16.689 ± 0.044 ns/op MultipleWithLoads.storeStore avgt 3 14.012 ± 0.010 ns/op // Better MultipleWithStores.plain avgt 3 14.687 ± 0.009 ns/op MultipleWithStores.release avgt 3 45.393 ± 0.192 ns/op MultipleWithStores.storeStore avgt 3 38.048 ± 0.033 ns/op // Better Publishing.plain avgt 3 27.079 ± 0.201 ns/op Publishing.release avgt 3 27.088 ± 0.241 ns/op Publishing.storeStore avgt 3 27.009 ± 0.259 ns/op // Within error, hidden by allocation Single.plain avgt 3 2.670 ± 0.002 ns/op Single.releaseFence avgt 3 6.675 ± 0.001 ns/op Single.storeStoreFence avgt 3 8.012 ± 0.027 ns/op // Worse, seems to be ARM32 implementation artifact As expected, this does not affect x86_64 at all, because both `release` and `storeStore` are effectively no-ops, only affecting compiler optimizations: Benchmark Mode Cnt Score Error Units Multiple.plain avgt 3 0.406 ± 0.002 ns/op Multiple.release avgt 3 0.409 ± 0.018 ns/op Multiple.storeStore avgt 3 0.406 ± 0.001 ns/op MultipleWithLoads.plain avgt 3 4.328 ± 0.006 ns/op MultipleWithLoads.release avgt 3 4.600 ± 0.014 ns/op MultipleWithLoads.storeStore avgt 3 4.602 ± 0.006 ns/op MultipleWithStores.plain avgt 3 0.812 ± 0.001 ns/op MultipleWithStores.release avgt 3 0.812 ± 0.002 ns/op MultipleWithStores.storeStore avgt 3 0.812 ± 0.002 ns/op Publishing.plain avgt 3 6.370 ± 0.059 ns/op Publishing.release avgt 3 6.358 ± 0.436 ns/op Publishing.storeStore avgt 3 6.367 ± 0.054 ns/op Single.plain avgt 3 0.407 ± 0.039 ns/op Single.releaseFence avgt 3 0.406 ± 0.001 ns/op Single.storeStoreFence avgt 3 0.406 ± 0.001 ns/op Additional testing: - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Formatting - Little cleanup - 8252990: Intrinsify Unsafe.storeStoreFence Changes: https://git.openjdk.java.net/jdk/pull/6136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6136&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252990 Stats: 39 lines in 16 files changed: 33 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6136/head:pull/6136 PR: https://git.openjdk.java.net/jdk/pull/6136

4 12

RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array
by q2q-2q2 02 Nov '21

02 Nov '21

Shortcut String equality checks by checking equality of the value array ------------- Commit messages: - JDK-8272192 Changes: https://git.openjdk.java.net/jdk/pull/5370/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5370&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272192 Stats: 62 lines in 3 files changed: 60 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5370.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5370/head:pull/5370 PR: https://git.openjdk.java.net/jdk/pull/5370

5 5

RFR: 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc
by Masanori Yano 02 Nov '21

02 Nov '21

Could you please review the 8276164 bug fixes? I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`. ------------- Commit messages: - 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Changes: https://git.openjdk.java.net/jdk/pull/6168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6168&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276164 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6168/head:pull/6168 PR: https://git.openjdk.java.net/jdk/pull/6168

2 4

RFR: 8275167: x86 intrinsic for unsignedMultiplyHigh
by Vamsi Parasa 02 Nov '21

02 Nov '21

Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction. This change show 1.87X improvement on a micro benchmark. ------------- Commit messages: - fix typo in function name - 8275167: x86 intrinsic for unsignedMultiplyHigh Changes: https://git.openjdk.java.net/jdk/pull/5933/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5933&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275167 Stats: 59 lines in 11 files changed: 59 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5933/head:pull/5933 PR: https://git.openjdk.java.net/jdk/pull/5933

5 19

RFR: 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976
by Brian Burkhalter 29 Oct '21

29 Oct '21

Please consider this proposed change to ignore comparing the total size of `/dev` as returned by `DF(1)` and `STAT(2)` on macOS. ------------- Commit messages: - 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Changes: https://git.openjdk.java.net/jdk/pull/6122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274750 Stats: 8 lines in 1 file changed: 7 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6122/head:pull/6122 PR: https://git.openjdk.java.net/jdk/pull/6122

3 12

RFR: 8276102: JDK-8245095 integration reverted JDK-8247980
by Aleksey Shipilev 29 Oct '21

29 Oct '21

See the [integration commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad5… ) for JDK-8245095. It reintroduced `java/util/stream` in `exclusiveAccess.dirs`, which effectively reverts JDK-8247980. I noticed this because jdk:tier1 became slow again. @FrauBoes, that was not intentional, right? The solution is to drop `java/util/stream` again. Additional testing: - [x] Linux x86_64 fastdebug `jdk:tier1` tests are fast again ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6153&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276102 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6153/head:pull/6153 PR: https://git.openjdk.java.net/jdk/pull/6153

4 5

RFR: 8262297: ImageIO.write() method will throw IndexOutOfBoundsException
by Masanori Yano 29 Oct '21

29 Oct '21

Could you please review the 8262297 bug fixes? In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed. ------------- Commit messages: - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException Changes: https://git.openjdk.java.net/jdk/pull/6151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262297 Stats: 96 lines in 4 files changed: 71 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/6151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151 PR: https://git.openjdk.java.net/jdk/pull/6151

4 6

RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior
by Mandy Chung 28 Oct '21

28 Oct '21

Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. ------------- Commit messages: - JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Changes: https://git.openjdk.java.net/jdk/pull/5901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274848 Stats: 379 lines in 4 files changed: 378 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901

4 10

RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert.
by Mitsuru Kariya 28 Oct '21

28 Oct '21

Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. (test31) 2. `pos - 1 + length > this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 (test32) 3. `pos == this.length() + 1` The original implementation throws `SerialException` but this case should end successfully. *2 (test33) Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: 1. `offset > str.length()` The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. (test39) 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. (test32) 3. `pos - 1 + length > this.length()` The original implementaion throws `SerialException` but this case should end successfully. *3 (test40) 4. `pos == this.length() + 1` The original implementaion throws `SerialException` but this case should end successfully. *4 (test41) The javadoc has also been modified according to the above. *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the BLOB value. *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the CLOB value. ------------- Commit messages: - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Changes: https://git.openjdk.java.net/jdk/pull/4001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8153490 Stats: 179 lines in 4 files changed: 122 ins; 17 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/4001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001 PR: https://git.openjdk.java.net/jdk/pull/4001

5 24

RFR: JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem
by Mandy Chung 28 Oct '21

28 Oct '21

On, macOS 11.x, system libraries are loaded from dynamic linker cache. The libraries are no longer present on the filesystem. `NativeLibraries::loadLibrary` checks for the file existence before calling `JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes that on macOS >= 11, it will skip the file existence check and attempt to load a library for each path from java.library.path and system library path. ------------- Commit messages: - trim whitespaces - add copyright header - fix typo - JDK-8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem Changes: https://git.openjdk.java.net/jdk/pull/6127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275703 Stats: 198 lines in 9 files changed: 170 ins; 2 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/6127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6127/head:pull/6127 PR: https://git.openjdk.java.net/jdk/pull/6127

6 12