July 2021 - core-libs-dev

RFR: 8268113: Re-use Long.hashCode() where possible
by Сергей Цыпанов 02 Aug '21

02 Aug '21

There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ------------- Commit messages: - 8268113: Re-use Long.hashCode() where possible Changes: https://git.openjdk.java.net/jdk/pull/4309/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268113 Stats: 10 lines in 7 files changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309

5 20

RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt()
by Сергей Цыпанов 02 Aug '21

02 Aug '21

`AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings): @Override public char charAt(int index) { checkIndex(index, count); if (isLatin1()) { return (char)(value[index] & 0xff); } return StringUTF16.charAt(value, index); } This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement: before Benchmark Mode Cnt Score Error Units StringBuilderCharAtBenchmark.latin avgt 50 2,768 ± 0,004 ns/op StringBuilderCharAtBenchmark.utf avgt 50 2,778 ± 0,014 ns/op after Benchmark Mode Cnt Score Error Units StringBuilderCharAtBenchmark.latin avgt 50 2,434 ± 0,004 ns/op StringBuilderCharAtBenchmark.utf avgt 50 2,631 ± 0,004 ns/op ------------- Commit messages: - 8270160 Remove redundant bounds check from AbstractStringBuilder.charAt() Changes: https://git.openjdk.java.net/jdk/pull/4738/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4738&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270160 Stats: 10 lines in 2 files changed: 1 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4738.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4738/head:pull/4738 PR: https://git.openjdk.java.net/jdk/pull/4738

2 9

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: 8269665: Clean-up toString() methods of some primitive wrappers
by Сергей Цыпанов 02 Aug '21

02 Aug '21

As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): public static String toString(byte b) { return Integer.toString((int)b, 10); } public String toString() { return Integer.toString((int)value); } Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ByteToStringBenchmark { @Benchmark public String byteToString() { return Byte.toString((byte) 1); } } Results: before Benchmark Mode Cnt Score Error Units ByteToStringBenchmark.byteToString avgt 30 11,648 ± 1,906 ns/op ByteToStringBenchmark.byteToString:·gc.alloc.rate avgt 30 3288,576 ± 418,119 MB/sec ByteToStringBenchmark.byteToString:·gc.alloc.rate.norm avgt 30 48,001 ± 0,001 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space avgt 30 3301,804 ± 455,932 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space.norm avgt 30 48,158 ± 2,085 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space avgt 30 0,004 ± 0,001 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm avgt 30 ≈ 10⁻⁴ B/op ByteToStringBenchmark.byteToString:·gc.count avgt 30 202,000 counts ByteToStringBenchmark.byteToString:·gc.time avgt 30 413,000 ms after Benchmark Mode Cnt Score Error Units ByteToStringBenchmark.byteToString avgt 30 10,016 ± 0,530 ns/op ByteToStringBenchmark.byteToString:·gc.alloc.rate avgt 30 3673,700 ± 167,450 MB/sec ByteToStringBenchmark.byteToString:·gc.alloc.rate.norm avgt 30 48,001 ± 0,001 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space avgt 30 3662,406 ± 205,978 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space.norm avgt 30 47,870 ± 1,750 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space avgt 30 0,004 ± 0,002 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm avgt 30 ≈ 10⁻⁴ B/op ByteToStringBenchmark.byteToString:·gc.count avgt 30 224,000 counts ByteToStringBenchmark.byteToString:·gc.time avgt 30 358,000 ms ------------- Commit messages: - 8269665: Clean-up toString() methods of some primitive wrappers Changes: https://git.openjdk.java.net/jdk/pull/4633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269665 Stats: 10 lines in 4 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4633/head:pull/4633 PR: https://git.openjdk.java.net/jdk/pull/4633

2 7

RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
by Sergey Chernyshev 30 Jul '21

30 Jul '21

Dear colleagues, Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below. I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue. [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/by… Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310), it increases MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. ![StartupTime](https://user-images.githubusercontent.com/6394632/126822380-5b01ce90-b249-4294-9a62-8269440f942d.png) ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png) I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310). [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip) ------------- Commit messages: - 8270321: Startup regressions in 18-b5 caused by JDK-8266310 Changes: https://git.openjdk.java.net/jdk/pull/4893/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4893&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270321 Stats: 35 lines in 1 file changed: 17 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/4893.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4893/head:pull/4893 PR: https://git.openjdk.java.net/jdk/pull/4893

5 9

PhantomReferences
by Hans Boehm 30 Jul '21

30 Jul '21

Here's another finalization-related issue, this time hopefully appropriate for this list. This was inspired by looking at the Ugawa, Jones, and Ritson paper from ISMM 2014, which I belatedly had a chance to look at. The java.lang.ref spec says: "An object is phantom reachable if it is neither strongly, softly, nor weakly reachable, it has been finalized, and some phantom reference refers to it." It notably does not say that such an object must not be reachable from unfinalized objects. I currently believe that: 1) This spec is not as intended, in that it allows a PhantomReference to X to be enqueued while X is still actively being used. My understanding is that PhantomReferences were invented largely to make that impossible. 2) Real production implementations enforce a stronger requirement, which includes that the PhantomReference must not reachable from unfinalized objects with a nontrivial finalizer, which prevents this problem. 3) The ISMM 2014 paper may have been confused by this, in that it seems to mirror the official spec rather than the usual implementation. It (surprisingly to me) does not appear to address the fact that implementations generally mark reachable objects in at least two stages: (1) Reachability from roots, and (2) Reachability from roots U unfinalized finalizable objects, where the result of the first phase is used to determine WeakReference clearing, while the result of the second phase determines PhantomReference clearing, and what to collect. Am I correct? A scenario that I believe can fail according to the spec, but cannot and must not fail in real life, is the following, where F1 and F2 are objects with nontrivial finalizers, and P is the referent of a PhantomReference: Consider F1 --> P, where P has a PhantomReference referring to it, and <root> -> F2 -> null. Then 1) F1's finalizer runs and notionally P's (empty) finalizer runs. F1 modifies F2, so it gets a strong reference to P. [ P has now been finalized. We have <root> -> F2 -> P ] 2) <root> is cleared, making F2 unreachable. [ P is not strongly, softly or weakly referenced, and has been finalized. Therefore P is phantom reachable. ] 3) The PhantomReference to P is enqueued, resulting in running a Cleaner that e.g. deallocates native memory required by P. 4) F2's finalizer runs and accesses P. 5) Bad stuff. Although this is arguably a weird corner case that is unlikely to occur frequently, I think it profoundly changes the algorithms used to implement this. "Has been finalized" is not the correct check; it's reachability from a not-yet-finalized object that matters. Hence the implementation must do a reachability analysis not technically required by the current spec. [ Just saying that in the spec probably doesn't work either. I suspect the fact that the finalizer is nontrivial also matters to get reasonable progress guarantees. Currently I think the spec doesn't have that notion, but it seems annoyingly essential. ] Clearly, this problem goes away if you get rid of finalizers and merge {Phantom,Weak}References, which is presumably the intended end state, but not one that looks imminent to me. Hans

2 1

RFR: Merge jdk17
by Jesper Wilhelmsson 29 Jul '21

29 Jul '21

Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8271489: (doc) Clarify Filter Factory example The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4939&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4939&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4939/files Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4939/head:pull/4939 PR: https://git.openjdk.java.net/jdk/pull/4939

1 2

[jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
by Roger Riggs 29 Jul '21

29 Jul '21

Improve the clarity of comments in the ObjectInputFilter FilterInThread example. ------------- Commit messages: - 8271489: (doc) Clarify Filter Factory example Changes: https://git.openjdk.java.net/jdk17/pull/293/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=293&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271489 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk17/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/293/head:pull/293 PR: https://git.openjdk.java.net/jdk17/pull/293

5 5

[jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
by Roger Riggs 29 Jul '21

29 Jul '21

Improve the clarity of comments in the ObjectInputFilter FilterInThread example. ------------- Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" - 8269763: The JEditorPane is blank after JDK-8265167 - 8265580: Enhanced style for RTF kit - 8265574: Improve handling of sheets - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561 Changes: https://git.openjdk.java.net/jdk17/pull/292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271489 Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod Patch: https://git.openjdk.java.net/jdk17/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk17/pull/292

1 1

RFR: 8271396: Spelling errors
by Emmanuel Bourg 29 Jul '21

29 Jul '21

This PR fixes the following spelling errors: choosen -> chosen commad -> command hiearchy -> hierarchy leagacy -> legacy minium -> minimum subsytem -> subsystem unamed -> unnamed ------------- Commit messages: - 8271396: Fix spelling errors Changes: https://git.openjdk.java.net/jdk/pull/2385/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2385&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271396 Stats: 78 lines in 34 files changed: 0 ins; 0 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/2385.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2385/head:pull/2385 PR: https://git.openjdk.java.net/jdk/pull/2385

9 16