April 2021 - core-libs-dev

RFR: 8265173: [test] divert spurious log output away from stream under test in ProcessBuilder Basic test
by Roger Riggs 15 Apr '21

15 Apr '21

The most recent intermittent failure showed that the error occurred during VM initialization. Only the tty output was diverted, but not log output. Add diversion of log output as well tty output. Add `-Xlog:all=warning:stderr` and `-Xlog:all=warning:stdout` to correspond to `-XX:+DisplayVMOutputToStderr` and `-XX:+DisplayVMOutputToStdout` ------------- Commit messages: - 8265173: [test] divert spurious log output away from stream under test in ProcessBuilder Basic test Changes: https://git.openjdk.java.net/jdk/pull/3492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265173 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3492/head:pull/3492 PR: https://git.openjdk.java.net/jdk/pull/3492

2 3

Garbage Free Check
by Ralph Goers 15 Apr '21

15 Apr '21

Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the minimum. In doing so I am encountering unit test errors while verifying that logging is garbage free. They all occur allocating an Instant. The code we have simply does public void init(MutableInstant mutableInstant) { Instant instant = java.time.Clock.systemUTC().instant(); mutableInstant.initFromEpochSecond(instant.getEpochSecond(), instant.getNano()); } In our previous tests we had thought the allocation was being eliminated due to escape analysis since the data is being extracted from the Instant and not passed along. However, after upgrading the Google test library and the JDK version it appears that is not the case. Ideally we would really like something like public void init(MutableInstant mutableInstant) { java.time.Clock.systemUTC().initInstant(mutableInstant); } where Mutable instant would implement an interface that has the two set methods.The method would execute the same logic that is in the instant() method but instead of creating a new Instant it would call the set methods for the provided object. This would allow us to either have the MutableInstants in ThreadLocals or some other mechanism to ensure they are thread safe and have no heap allocations. As it stands now I see no way to gain access to the higher precision clock without memory allocation. Do you know of another way to do this? Am I missing something? Ralph

5 10

RFR: JDK-8265078: jpackage tests on Windows leave large temp files
by Andy Herrick 14 Apr '21

14 Apr '21

two changes: One to jpackage, when recursively removing directory, when IOException occurs, record it and continue (deleting as much as possible) before throwing the exception. The other to tests, when running jpackage via ProcessBuilder.execute(), set the "TMP" environment variable to the current value of System Property "java.io.tmpdir". This causes the sub-process (jpackage) to output tmp files to the tmp file location used by the test. (So the test harness can clean up after test exits). ------------- Commit messages: - JDK-8265078: jpackage tests on Windows leave large temp files Changes: https://git.openjdk.java.net/jdk/pull/3473/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3473&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265078 Stats: 29 lines in 3 files changed: 27 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3473.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3473/head:pull/3473 PR: https://git.openjdk.java.net/jdk/pull/3473

3 13

RFR: 8262883: doccheck: Broken links in java.base
by Michael McMahon 14 Apr '21

14 Apr '21

Hi, Could I get the following trivial doc changes reviewed please, caused by: - broken <A> tags in MethodHandles referring to package.html instead of package-summary.html - references to a package level #unixdomain anchor that no longer exists. - a <a> tag missing a "../" in SocketChannel Thanks, Michael ------------- Commit messages: - Fixed SocketChannel - fixed links in apidoc Changes: https://git.openjdk.java.net/jdk/pull/3491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262883 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3491/head:pull/3491 PR: https://git.openjdk.java.net/jdk/pull/3491

4 5

RFR: 8264976: Minor numeric bug in AbstractSplittableWithBrineGenerator.makeSplitsSpliterator
by Aleksey Shipilev 14 Apr '21

14 Apr '21

SonarCloud reports: Cast one of the operands of this subtraction operation to a "long". Here: Spliterator<SplittableGenerator> makeSplitsSpliterator(long index, long fence, SplittableGenerator source) { ... long multiplier = (1 << SALT_SHIFT) - 1; // <---- here The shift is integer, and the cast to long is too late. `SALT_SHIFT` is currently 4, so this is not the problem. But it would become a problem if `SALT_SHIFT` ever becomes 32 or larger. The shift operand should be `1L` for safety. Observe: jshell> Long.toHexString((1 << 31) - 1) $2 ==> "7fffffff" jshell> Long.toHexString((1 << 32) - 1) $3 ==> "0" jshell> Long.toHexString((1L << 32) - 1) $4 ==> "ffffffff" Additional testing: - [x] Linux x86_64 fastdebug, `jdk/utils/Random` ------------- Commit messages: - 8264976: Minor numeric bug in AbstractSplittableWithBrineGenerator.makeSplitsSpliterator Changes: https://git.openjdk.java.net/jdk/pull/3409/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264976 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3409/head:pull/3409 PR: https://git.openjdk.java.net/jdk/pull/3409

3 4

RFR: 8265174: Update Class.getDeclaredMethods to discuss synethetic and bridge methods
by Joe Darcy 14 Apr '21

14 Apr '21

The results from Class.getDeclaredMethods can include bridge and other synthetic methods, which can be unexpected by users (JDK-6815786, JDK-8142904) and appear to be inherited methods. The javadoc for Class.getDeclaredMethods should be updated to explicitly mention the possibility of synthetic methods appearing. ------------- Commit messages: - 8265174: Update Class.getDeclaredMethods to discuss synethetic and bridge methods Changes: https://git.openjdk.java.net/jdk/pull/3477/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3477&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265174 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3477.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3477/head:pull/3477 PR: https://git.openjdk.java.net/jdk/pull/3477

2 3

RFR: 8265019 : Update tests for additional TestNG test permissions
by Lance Andersen 14 Apr '21

14 Apr '21

Hi all, Please review the following patch which adds additional permissions needed for when JTREG upgrades to a newer version of TestNG. Best, Lance ------------- Commit messages: - TestNG updates Changes: https://git.openjdk.java.net/jdk/pull/3471/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3471&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265019 Stats: 21 lines in 2 files changed: 11 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3471/head:pull/3471 PR: https://git.openjdk.java.net/jdk/pull/3471

5 8

RFR: 8265075: Improve and simplify Class.resolveName()
by Сергей Цыпанов 14 Apr '21

14 Apr '21

In mentioned method this code snippet int len = baseName.length() + 1 + name.length(); StringBuilder sb = new StringBuilder(len); name = sb.append(baseName.replace('.', '/')) .append('/') .append(name) .toString(); can be simplified with performance improvement as name = baseName.replace('.', '/') + '/' + name; Also null check of `baseName` can be removed as Class.getPackageName() never returns null. This benchmark @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ResolveNameBenchmark { private final Class<? extends ResolveNameBenchmark> klazz = getClass(); @Benchmark public Object original() { return original("com/tsypanov/ovn/ResolveNameBenchmark.class"); } @Benchmark public Object patched() { return patched("com/tsypanov/ovn/ResolveNameBenchmark.class"); } private String original(String name) { if (!name.startsWith("/")) { String baseName = getPackageName(); if (baseName != null && !baseName.isEmpty()) { int len = baseName.length() + 1 + name.length(); StringBuilder sb = new StringBuilder(len); name = sb.append(baseName.replace('.', '/')) .append('/') .append(name) .toString(); } } else { name = name.substring(1); } return name; } private String patched(String name) { if (!name.startsWith("/")) { String baseName = getPackageName(); if (!baseName.isEmpty()) { return baseName.replace('.', '/') + '/' + name; } return name; } return name.substring(1); } private String getPackageName() { return klazz.getPackageName(); } } demonstrates good improvement, especially as of memory consumption: Mode Cnt Score Error Units original avgt 50 57.974 ± 0.365 ns/op original:·gc.alloc.rate avgt 50 3419.447 ± 21.154 MB/sec original:·gc.alloc.rate.norm avgt 50 312.006 ± 0.001 B/op original:·gc.churn.G1_Eden_Space avgt 50 3399.396 ± 149.836 MB/sec original:·gc.churn.G1_Eden_Space.norm avgt 50 310.198 ± 13.628 B/op original:·gc.churn.G1_Survivor_Space avgt 50 0.004 ± 0.001 MB/sec original:·gc.churn.G1_Survivor_Space.norm avgt 50 ≈ 10⁻³ B/op original:·gc.count avgt 50 208.000 counts original:·gc.time avgt 50 224.000 ms patched avgt 50 44.367 ± 0.162 ns/op patched:·gc.alloc.rate avgt 50 2749.265 ± 10.014 MB/sec patched:·gc.alloc.rate.norm avgt 50 192.004 ± 0.001 B/op patched:·gc.churn.G1_Eden_Space avgt 50 2729.221 ± 193.552 MB/sec patched:·gc.churn.G1_Eden_Space.norm avgt 50 190.615 ± 13.539 B/op patched:·gc.churn.G1_Survivor_Space avgt 50 0.003 ± 0.001 MB/sec patched:·gc.churn.G1_Survivor_Space.norm avgt 50 ≈ 10⁻⁴ B/op patched:·gc.count avgt 50 167.000 counts patched:·gc.time avgt 50 181.000 ms ------------- Commit messages: - 8265075: Improve and simplify Class.resolveName() Changes: https://git.openjdk.java.net/jdk/pull/3464/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3464&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265075 Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3464.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3464/head:pull/3464 PR: https://git.openjdk.java.net/jdk/pull/3464

3 9

Re: ObjectMethods seems generating wrong methods for array-type field
by Raffaello Giulietti 14 Apr '21

14 Apr '21

Hi Kengo, I don't think this is a bug, as records are designed to "act as transparent carriers for immutable data". A record having an array-typed component is far from being immutable because everyone can change the array contents. So you probably shouldn't opt for records for such use cases, since you would loose the semantic benefits of records. But if you need deeper hashing and comparison over array-typed components of records, as you are probably expecting in your example, you have to override the record hashCode() and equals() yourself. But then (http://openjdk.java.net/jeps/395) "Any explicit implementation of accessors or the equals or hashCode methods should be careful to preserve the semantic invariants of the record class." Greetings Raffaello > Hello there, > > > I'm Kengo TODA, an engineer learning about the Record feature. > Today I found a nonintentional behavior, and it seems that the bug database > has no info about it. > Let me ask here to confirm it's by-design or not. If it's a bug, I want to > try to send a patch to OpenJDK. > > Here is the code reproducing the nonintentional behavior: > https://gist.github.com/KengoTODA/4d7ef6a5226d347ad9385241fee6bc63 > > In short, the ObjectMethods class in OpenJDK v16 generates code > that invokes the fields' method, even when the field is an array. > > Please help me to understand this behavior, or > make an entry in the bug database to propose a patch. > Thanks in advance! :) > > *** > Kengo TODA > skypencil at gmail.com

1 0

RFR: 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles
by Per Liden 14 Apr '21

14 Apr '21

JDK-8240679 introduced a change where the information exposed via the GarbageCollectorMXBean went from being related to the GC pauses to instead be related to the GC cycles. This helped provide more accurate heap usage information. However, some users have noticed that that you no longer get timing information related to the GC pauses, only related to the GC cycle. Shenandoah has opted for having two distinct memory managers to provide timing information about both pauses and cycles. To align how concurent GCs report this information, ZGC should probably do the same. Testing: * Tier1-7 with ZGC * Manual testing with relevant jtreg tests ------------- Commit messages: - 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles Changes: https://git.openjdk.java.net/jdk/pull/3483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3483&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265136 Stats: 179 lines in 9 files changed: 107 ins; 25 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/3483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3483/head:pull/3483 PR: https://git.openjdk.java.net/jdk/pull/3483

1 0