May 2021 - core-libs-dev

RFR: 8257733: Move module-specific data from make to respective module
by Magnus Ihse Bursie 21 Mar '22

21 Mar '22

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. ------------- Commit messages: - Update references in test - Step 2: Update references - First stage, move actual data files Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257733 Stats: 78 lines in 1575 files changed: 3 ins; 1 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611

13 79

RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
by Lance Andersen 09 Mar '22

09 Mar '22

Hi, Please review the fix for JDK-8256018 which addresses the issue that the update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly. The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the jck:api/java_util/zip,jck:api/java_util/jar continue to run clean. Best Lance ------------- Commit messages: - Adler32/CRC32/CRC32C missing reachabilityFence Changes: https://git.openjdk.java.net/jdk/pull/1149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256018 Stats: 23 lines in 3 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1149/head:pull/1149 PR: https://git.openjdk.java.net/jdk/pull/1149

4 6

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: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields
by Lin Zang 30 Sep '21

30 Sep '21

4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields ------------- Commit messages: - remove trailing spaces - 4890732: support optional GZIP fields in GZIPOutputStream Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4890732 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072

5 46

RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0
by Roger Riggs 24 Sep '21

24 Sep '21

On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property and the version number provided by `sw_vers -productVersion`. When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 though the current version numbering is 11.nnn. The workaround is to derive the os.version number from the ProductBuildVersion. When the toolchain is updated to XCode 12.nnn it can be removed. The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. ------------- Commit messages: - 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 Changes: https://git.openjdk.java.net/jdk/pull/2530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253702 Stats: 30 lines in 1 file changed: 21 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530

5 20

RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
by Jim Laskey 14 Sep '21

14 Sep '21

This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random… old PR: https://github.com/openjdk/jdk/pull/1273 ------------- Commit messages: - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862; Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7 Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248862 Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292

14 110

RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods
by Aleksey Shipilev 04 Aug '21

04 Aug '21

Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). Interpreter-only "Hello World": Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) OpenLiberty startup: Before: 2.296, 2.281, 2.291 (seconds) After: 2.254, 2.267, 2.272 (seconds) Additional tests: - [x] Linux `tier1` default (passes) - [x] Linux `tier1` `-XX:-CompactStrings` ------------- Commit messages: - Merge branch 'master' into JDK-8260710-string-inline - Merge branch 'master' into JDK-8260710-string-inline - Initial prototype Changes: https://git.openjdk.java.net/jdk/pull/2334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260710 Stats: 173 lines in 5 files changed: 5 ins; 48 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/2334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2334/head:pull/2334 PR: https://git.openjdk.java.net/jdk/pull/2334

5 5

RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available
by Сергей Цыпанов 02 Aug '21

02 Aug '21

Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. However the code like private String getSimpleName0() { if (isArray()) { return getComponentType().getSimpleName() + "[]"; } //... } can be improved via replacement of `+` with `String.concat()` call. I've used this benchmark to measure impact: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ClassMethodsBenchmark { private final Class<? extends Object[]> arrayClass = Object[].class; private Method descriptorString; @Setup public void setUp() throws NoSuchMethodException { //fore some reason compiler doesn't allow me to call Class.descriptorString() directly descriptorString = Class.class.getDeclaredMethod("descriptorString"); } @Benchmark public Object descriptorString() throws Exception { return descriptorString.invoke(arrayClass); } @Benchmark public Object typeName() { return arrayClass.getTypeName(); } } and got those results Mode Cnt Score Error Units descriptorString avgt 60 91.480 ± 1.839 ns/op descriptorString:·gc.alloc.rate.norm avgt 60 404.008 ± 4.033 B/op descriptorString:·gc.churn.G1_Eden_Space avgt 60 2791.866 ± 181.589 MB/sec descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 401.702 ± 26.047 B/op descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻³ B/op descriptorString:·gc.count avgt 60 205.000 counts descriptorString:·gc.time avgt 60 216.000 ms patched Mode Cnt Score Error Units descriptorString avgt 60 65.016 ± 3.446 ns/op descriptorString:·gc.alloc.rate avgt 60 2844.240 ± 115.719 MB/sec descriptorString:·gc.alloc.rate.norm avgt 60 288.006 ± 0.001 B/op descriptorString:·gc.churn.G1_Eden_Space avgt 60 2832.996 ± 206.939 MB/sec descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 286.955 ± 17.853 B/op descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻³ B/op descriptorString:·gc.count avgt 60 208.000 counts descriptorString:·gc.time avgt 60 228.000 ms ----------------- typeName avgt 60 34.273 ± 0.480 ns/op typeName:·gc.alloc.rate avgt 60 3265.356 ± 45.113 MB/sec typeName:·gc.alloc.rate.norm avgt 60 176.004 ± 0.001 B/op typeName:·gc.churn.G1_Eden_Space avgt 60 3268.454 ± 134.458 MB/sec typeName:·gc.churn.G1_Eden_Space.norm avgt 60 176.109 ± 6.595 B/op typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec typeName:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻⁴ B/op typeName:·gc.count avgt 60 240.000 counts typeName:·gc.time avgt 60 255.000 ms patched typeName avgt 60 15.787 ± 0.214 ns/op typeName:·gc.alloc.rate avgt 60 2577.554 ± 32.339 MB/sec typeName:·gc.alloc.rate.norm avgt 60 64.001 ± 0.001 B/op typeName:·gc.churn.G1_Eden_Space avgt 60 2574.039 ± 147.774 MB/sec typeName:·gc.churn.G1_Eden_Space.norm avgt 60 63.895 ± 3.511 B/op typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec typeName:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻⁴ B/op typeName:·gc.count avgt 60 189.000 counts typeName:·gc.time avgt 60 199.000 ms I think this patch is likely to improve reflection operations related to arrays. If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible. Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here. ------------- Commit messages: - Use String.concat() where invokedynamic-based String concatenation is not available Changes: https://git.openjdk.java.net/jdk/pull/3627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266972 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627 PR: https://git.openjdk.java.net/jdk/pull/3627

5 17

RFR: 8266054: VectorAPI rotate operation optimization
by Jatin Bhateja 28 Jul '21

28 Jul '21

Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- vec1 = lanewise(VectorOperators.LSHL, n) vec2 = lanewise(VectorOperators.LSHR, n) res = lanewise(VectorOperations.OR, vec1 , vec2) This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. Please find below the performance data for included JMH benchmark. Machine: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascaselake Server) `` Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain % -- | -- | -- | -- | -- RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81 RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85 RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25 RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11 RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89 RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32 RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45 RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78 RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92 RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38 RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23 RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36 RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92 RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19 RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85 RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73 RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96 RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73 RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01 RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52 RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76 RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15 RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51 RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66 RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63 RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05 RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83 RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96 RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39 RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22 RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30 RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49 RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74 RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82 RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86 RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49 `` ------------- Commit messages: - 8266054: Changing gen-src.sh file permissions - 8266054: VectorAPI rotate operation optimization Changes: https://git.openjdk.java.net/jdk/pull/3720/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266054 Stats: 1282 lines in 45 files changed: 1201 ins; 58 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720 PR: https://git.openjdk.java.net/jdk/pull/3720

4 34

RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand
by Andrey Turbanov 26 Jul '21

26 Jul '21

I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`. This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value. Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR. ------------- Commit messages: - 8265474: Dubious 'null' assignment in CompactByteArray.expand - [PATCH] Remove dubious 'null' assignment to CompactByteArray.values Changes: https://git.openjdk.java.net/jdk/pull/1880/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1880&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265474 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1880/head:pull/1880 PR: https://git.openjdk.java.net/jdk/pull/1880

3 4