April 2020 - core-libs-dev

RFR 15 8225319: Remove the RMI static stub compiler rmic
by Roger Riggs 07 Apr '20

07 Apr '20

Please review the CSR[1] and changes to remove the RMI static stub compiler (rmic). RMIC was deprecated for removal in JDK 13 [3]. The components modified are: - remove the jdk.rmic module - remove the jdk.rmic man page - remove all tests of rmic or relying on rmic - update or remove makefiles to remove references and dependencies on rmic - update source files in java.rmi module to remove extraneous references to rmic Wevrev: http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 Thanks, Roger [1] CSR: https://bugs.openjdk.java.net/browse/JDK-8242049 [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8225319 [3] Deprecate rmic for removal https://bugs.openjdk.java.net/browse/JDK-8217412

6 7

JDK 15 RFR of JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations
by Joe Darcy 06 Apr '20

06 Apr '20

Hello, Please review the changes to fix JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations http://cr.openjdk.java.net/~darcy/8225540.1/ This is a sibling fix to JDK-8225495 already done over in javax.lang.model. In brief, the purpose of the change is to make explicit whether declaration annotations (that is traditional annotations in the platform since JDK 5.0) or type annotations (added in JDK 8) are being returned by the various annotation-returning methods. The distinctions between the two kinds of annotations are discussed in the cited sections of JLS. The root interface of types that can return annotations is AnnotatedElement. Some of the wording developed for JDK-8225495 is borrowed and repurposed as a general explanation in AnnotatedElement. The implementation specification of the default method for AnnotatedElement.isAnnotationPresetn is pull out to properly use an @implSpec tag. The AnnotatedType interface and its subinterfaces return type annotations; the other class and interfaces return declaration annotations. For AnnotatedType, the three methods on AnnotatedElement that do *not* have default methods are overriden for the sole purpose of adding a note stating any return annotations are *type* annotations. The specs of the default methods rely on the behavior of the non-default methods so this implicitly implies the results of the other methods are type annotations too. Since there is no common superclass of the various classes which can return declaration annotations, analogous notes are spread through many classes including * java.lang.Class * java.lang.Package * java.lang.Module * java.reflect.{AccessibleObject, Executable, Constructor, Method, Field, Parameter, RecordComponent} These classes are also updated to use @Override consistently for the annotation-related methods; @Override couldn't initially be used on interface methods implemented by a class. The Executable.getParameterAnnotations method also get a note to state it returns declaration annotations. I'll update copyright and reflow paragraphs before pushing. Thanks, -Joe

1 0

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
by Mandy Chung 06 Apr '20

06 Apr '20

On 4/6/20 9:56 AM, serguei.spitsyn(a)oracle.com wrote: > > The suggested fix is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8… > This patch looks okay. I'll include in my local patch. On 4/6/20 11:00 AM, Chris Plummer wrote: > > I think that's fine but I don't think it should be done in the context > of this Vahalla webrev since it has nothing to do with Vahalla. I'd > suggest filing an RFE and pushing it to jdk/jdk. Easier to track that > way if there are issues down the road. > I am okay to follow up as a separate RFE. thanks Mandy

2 1

[NEW BUG] Reduce allocations from Class.toString() for primitives
by Christoph Dreis 06 Apr '20

06 Apr '20

Hi, I just noticed an opportunity to optimize Class.toString() for primitive types. I've written a small benchmark and ran it against JDK 15 vs a patched variant. @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private Class<?> primitive = long.class; private Class<?> clazz = Long.class; private Class<?> interfaze = Map.class; } @Benchmark public String testPrimitive(ThreadState threadState) { return threadState.primitive.toString(); } @Benchmark public String testClass(ThreadState threadState) { return threadState.clazz.toString(); } @Benchmark public String testInterface(ThreadState threadState) { return threadState.interfaze.toString(); } } This yields the following results: Before Benchmark Mode Cnt Score Error Units MyBenchmark.testClass avgt 10 32,268 ± 2,961 ns/op MyBenchmark.testClass:·gc.alloc.rate avgt 10 3601,964 ± 336,786 MB/sec MyBenchmark.testClass:·gc.alloc.rate.norm avgt 10 152,009 ± 0,001 B/op MyBenchmark.testClass:·gc.count avgt 10 203,000 counts MyBenchmark.testClass:·gc.time avgt 10 138,000 ms MyBenchmark.testInterface avgt 10 37,685 ± 3,728 ns/op MyBenchmark.testInterface:·gc.alloc.rate avgt 10 3086,794 ± 309,983 MB/sec MyBenchmark.testInterface:·gc.alloc.rate.norm avgt 10 152,008 ± 0,001 B/op MyBenchmark.testInterface:·gc.count avgt 10 160,000 counts MyBenchmark.testInterface:·gc.time avgt 10 107,000 ms MyBenchmark.testPrimitive avgt 10 20,937 ± 2,668 ns/op MyBenchmark.testPrimitive:·gc.alloc.rate avgt 10 3809,437 ± 470,140 MB/sec MyBenchmark.testPrimitive:·gc.alloc.rate.norm avgt 10 104,006 ± 0,001 B/op MyBenchmark.testPrimitive:·gc.count avgt 10 215,000 counts MyBenchmark.testPrimitive:·gc.time avgt 10 167,000 ms After Benchmark Mode Cnt Score Error Units MyBenchmark.testClass avgt 10 31,585 ± 5,365 ns/op MyBenchmark.testClass:·gc.alloc.rate avgt 10 3704,714 ± 549,224 MB/sec MyBenchmark.testClass:·gc.alloc.rate.norm avgt 10 152,008 ± 0,001 B/op MyBenchmark.testClass:·gc.count avgt 10 191,000 counts MyBenchmark.testClass:·gc.time avgt 10 139,000 ms MyBenchmark.testInterface avgt 10 34,534 ± 2,073 ns/op MyBenchmark.testInterface:·gc.alloc.rate avgt 10 3358,401 ± 193,391 MB/sec MyBenchmark.testInterface:·gc.alloc.rate.norm avgt 10 152,008 ± 0,001 B/op MyBenchmark.testInterface:·gc.count avgt 10 173,000 counts MyBenchmark.testInterface:·gc.time avgt 10 131,000 ms MyBenchmark.testPrimitive avgt 10 2,829 ± 0,139 ns/op MyBenchmark.testPrimitive:·gc.alloc.rate avgt 10 ≈ 10⁻⁴ MB/sec MyBenchmark.testPrimitive:·gc.alloc.rate.norm avgt 10 ≈ 10⁻⁶ B/op MyBenchmark.testPrimitive:·gc.count avgt 10 ≈ 0 counts I don't think the patched version is actually faster for classes & interfaces; I guess it's rather a draw for those. Yet, for primitives we can see a 10x improvement due to the avoided string concats. In case you think this is worthwhile I would need someone to sponsor this patch. I would highly appreciate that. Let me know what you think Cheers, Christoph ===== PATCH ===== diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java +++ b/src/java.base/share/classes/java/lang/Class.java @@ -196,8 +196,11 @@ * @return a string representation of this {@code Class} object. */ public String toString() { - return (isInterface() ? "interface " : (isPrimitive() ? "" : "class ")) - + getName(); + String name = getName(); + if (isPrimitive()) { + return name; + } + return (isInterface() ? "interface " : "class ") + name; }

2 1

Use Method.getParameterCount() where possible
by Christoph Dreis 06 Apr '20

06 Apr '20

Hi, I noticed that the JDK itself still uses Method.getParameterTypes().length in a couple of places. This could be replaced with Method.getParameterCount() to avoid unnecessary cloning overhead. While this is often optimized away, I guess it's still good to not rely on that. Additionally, it's a little more concise to read. If you think this is worthwhile, I would need someone to sponsor that tiny change. P.S.: There is another occurrence in ForkJoinTask where I wasn't sure if I should change that, because it's usually changed under the JSR166 umbrella afaik. Cheers, Christoph ==== PATCH ==== diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java @@ -276,13 +276,13 @@ switch (m.getName()) { case "toString": return (m.getReturnType() == String.class - && m.getParameterTypes().length == 0); + && m.getParameterCount() == 0); case "hashCode": return (m.getReturnType() == int.class - && m.getParameterTypes().length == 0); + && m.getParameterCount() == 0); case "equals": return (m.getReturnType() == boolean.class - && m.getParameterTypes().length == 1 + && m.getParameterCount() == 1 && m.getParameterTypes()[0] == Object.class); } return false; diff --git a/src/java.base/share/classes/java/lang/reflect/Executable.java b/src/java.base/share/classes/java/lang/reflect/Executable.java --- a/src/java.base/share/classes/java/lang/reflect/Executable.java +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java @@ -378,7 +378,7 @@ private void verifyParameters(final Parameter[] parameters) { final int mask = Modifier.FINAL | Modifier.SYNTHETIC | Modifier.MANDATED; - if (getParameterTypes().length != parameters.length) + if (getParameterCount() != parameters.length) throw new MalformedParametersException("Wrong number of parameters in MethodParameters attribute"); for (Parameter parameter : parameters) { diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java @@ -121,7 +121,7 @@ if (Modifier.isPublic(method.getModifiers()) && Modifier.isAbstract(method.getModifiers()) && !method.isSynthetic()) { - if (method.getParameterTypes().length != 0) { + if (method.getParameterCount() != 0) { throw new IllegalArgumentException(method + " has params"); } String name = method.getName();

3 3

[NEW BUG] Small optimization in URLStreamHandler.parseURL
by Christoph Dreis 06 Apr '20

06 Apr '20

Hi, I just noticed a small optimization opportunity in URLStreamHandler.parseURL for inputs like the following: new URL(new URL("file:"), "file:./path/to/some/local.properties"); In those cases there is no authority involved, which makes it possible to rewrite URLStreamHandler:L269-270: String separator = (authority != null) ? "/" : ""; path = separator + spec.substring(start, limit); into the following to avoid unnecessary string concatenations with an empty string: path = spec.substring(start, limit); path = (authority != null) ? "/" + path : path; I've written a small benchmark with two URLStreamHandler variants (one with the old parseURL and one with the new): @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private URL context; private URLStreamHandler newHandler = new NewURLStreamHandler(); private URLStreamHandler oldHandler = new OldURLStreamHandler(); private String spec = "file:./path/to/some/application.properties"; public ThreadState() { try { context = new URL("file:"); } catch (MalformedURLException ignored) { } } } @Benchmark public URL testNew(ThreadState threadState) throws MalformedURLException { return new URL(threadState.context, threadState.spec, threadState.newHandler); } @Benchmark public URL testOld(ThreadState threadState) throws MalformedURLException { return new URL(threadState.context, threadState.spec, threadState.oldHandler); } } The benchmark above yields the following results on my local machine: Benchmark Mode Cnt Score Error Units MyBenchmark.testNew avgt 10 112,655 ± 3,494 ns/op MyBenchmark.testNew:·gc.alloc.rate avgt 10 1299,558 ± 41,238 MB/sec MyBenchmark.testNew:·gc.alloc.rate.norm avgt 10 192,015 ± 0,003 B/op MyBenchmark.testNew:·gc.count avgt 10 98,000 counts MyBenchmark.testNew:·gc.time avgt 10 105,000 ms MyBenchmark.testOld avgt 10 128,592 ± 1,183 ns/op MyBenchmark.testOld:·gc.alloc.rate avgt 10 1612,743 ± 15,792 MB/sec MyBenchmark.testOld:·gc.alloc.rate.norm avgt 10 272,019 ± 0,001 B/op MyBenchmark.testOld:·gc.count avgt 10 110,000 counts MyBenchmark.testOld:·gc.time avgt 10 121,000 ms In case you think this is worthwhile I would need someone to sponsor the attached patch for me. I would highly appreciate that. Cheers, Christoph ===== PATCH ===== diff --git a/src/java.base/share/classes/java/net/URLStreamHandler.java b/src/java.base/share/classes/java/net/URLStreamHandler.java --- a/src/java.base/share/classes/java/net/URLStreamHandler.java +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java @@ -266,8 +266,8 @@ spec.substring(start, limit); } else { - String separator = (authority != null) ? "/" : ""; - path = separator + spec.substring(start, limit); + path = spec.substring(start, limit); + path = (authority != null) ? "/" + path : path; } } else if (queryOnly && path != null) { int ind = path.lastIndexOf('/');

3 4

[PATCH] Trivial improvement for j.l.Character.toString()
by Сергей Цыпанов 06 Apr '20

06 Apr '20

Hello, I think we can reduce allocation rate for j.l.Character.toString() by calling String.valueOf(char) instead of String.valueOf(char[]). Current implementation creates char[] with one char which is later decoded into byte[]. Instead String.valueOf(char) decodes char directly consuming less memory. I've used benchmark [1] and on my machine got those results (JDK 14): Benchmark Mode Score Error Units CharacterToStringBenchmark.toString_utf8 avgt 14.723 ± 1.354 ns/op CharacterToStringBenchmark.valueOf_utf8 avgt 7.678 ± 0.601 ns/op CharacterToStringBenchmark.toString_latin avgt 10.992 ± 1.371 ns/op CharacterToStringBenchmark.valueOf_latin avgt 7.844 ± 1.044 ns/op CharacterToStringBenchmark.toString_utf8:·gc.alloc.rate.norm avgt 96.003 ± 0.001 B/op CharacterToStringBenchmark.valueOf_utf8:·gc.alloc.rate.norm avgt 48.002 ± 0.001 B/op CharacterToStringBenchmark.toString_latin:·gc.alloc.rate.norm avgt 72.003 ± 0.001 B/op CharacterToStringBenchmark.valueOf_latin:·gc.alloc.rate.norm avgt 48.002 ± 0.001 B/op Patch is below. With best regards, Sergey Tsypanov [1] https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/stri… diff --git a/src/java.base/share/classes/java/lang/Character.java b/src/java.base/share/classes/java/lang/Character.java --- a/src/java.base/share/classes/java/lang/Character.java +++ b/src/java.base/share/classes/java/lang/Character.java @@ -3285,7 +3285,7 @@ "SYMBOLS AND PICTOGRAPHS EXTENDED-A", "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); - private static final int blockStarts[] = { + private static final int[] blockStarts = { 0x0000, // 0000..007F; Basic Latin 0x0080, // 0080..00FF; Latin-1 Supplement 0x0100, // 0100..017F; Latin Extended-A @@ -8068,7 +8068,7 @@ UNKNOWN, // E01F0..10FFFF }; - private static HashMap<String, Character.UnicodeScript> aliases; + private static final HashMap<String, Character.UnicodeScript> aliases; static { aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); aliases.put("ADLM", ADLAM); @@ -8421,8 +8421,7 @@ * @return a string representation of this object. */ public String toString() { - char buf[] = {value}; - return String.valueOf(buf); + return toString(value); } /**

4 5

Re: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg (Andy Herrick)
by James Elliott 03 Apr '20

03 Apr '20

This sounds promising! I just wanted to check if there is a mechanism to specify a custom set of entitlements needed by the application when running jpackage, in case it needs more than the normal set that Java itself does. Or does Java already ask for every possible entitlement in its original notarization? Thanks, -James > Date: Fri, 3 Apr 2020 10:20:21 -0400 > From: Andy Herrick <andy.herrick(a)oracle.com> > To: core-libs-dev(a)openjdk.java.net > Subject: Re: RFR: JDK-8237490: [macos] Add support notarizing jpackage > app-image and dmg > Message-ID: <f3571d06-cfc4-ae42-53bc-a304630253f2(a)oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > sorry missing webrev pointer [4] > > [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 > > /Andy > > On 4/3/2020 9:24 AM, Andy Herrick wrote: >> please review this revised webrev [4] to issue [2] >> >> The previous version generated a signed app that could be notarized, >> but then couldn't run because signing the whole app resigned the >> executable with reduced entitlements. >> >> This revision adds back in the entitlements when signing the whole >> app, as well as fixing the unit test that was failing the spctl call >> on Catalina due to signed app not being notarized. >> >> >> /Andy >> >> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>> revised with minor fixes as per below - webrev at [3] >>> >>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>> >>> /Andy >>> >>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>> >>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>> Hi Andy, >>>>> >>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpa… >>>>> >>>>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>>>> align with rest of code. >>>> I will fix this. >>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpa… >>>>> >>>>> Line 70 - Capital F. >>>> and this >>>>> >>>>> Since we added "--timestamp" and? "--options runtime" to codesign, >>>>> will it work with older Xcode and macOS we planning to support? >>>> not sure - may need some discussion of what we support and possible >>>> conditional code here. >>>>> >>>>> Do we need any adjustments to signing tests we have? >>>> >>>> The existing tests pass, but this is not unexpected (and really >>>> means nothing) since the signing tests are all skipped unless >>>> specific test certs are installed on target machine. >>>> >>>> We need further discussion how one is expected to provision a >>>> machine to run these tests. >>>> >>>> /Andy >>>> >>>>> >>>>> Otherwise looks fine. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>> Please review the fix to issue [1] at [2]. >>>>>> >>>>>> This change enables notarization on Mac for dmg images and >>>>>> app-image zip files. >>>>>> >>>>>> /Andy >>>>>> >>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>> >>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>> >>>>> > > > End of core-libs-dev Digest, Vol 156, Issue 12 > ********************************************** >

2 1

Review Request 8238195: Lookup::defineClass should link the class to match the specification
by Mandy Chung 02 Apr '20

02 Apr '20

The spec of `Lookup::defineClass` specifies to throw linkage error including `VerifyError` and JDK-8238358 fixes the implementation to match the spec [1]. This patch updates the spec to make it clear as proposed in the CSR:https://bugs.openjdk.java.net/browse/JDK-8240338. Also add a new test case to verify that `defineClass` does link a class. Webrev at: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/ Thanks Mandy [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065456.html

3 3

RFR 8015413 Reformat line in Class.privateGetPublicFields() to be more debugger-friendly
by Vipin Mv1 01 Apr '20

01 Apr '20

Hi All, Please find the below changes for the issue https://bugs.openjdk.java.net/browse/JDK-8015413 diff -r 53568400fec3 src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java Thu Mar 26 15:26:51 2020 +0000 +++ b/src/java.base/share/classes/java/lang/Class.java Mon Mar 30 17:31:04 2020 +0530 @@ -3163,7 +3163,8 @@ ReflectionData<T> rd = reflectionData(); if (rd != null) { res = rd.publicFields; - if (res != null) return res; + if (res != null) + return res; } // Use a linked hash set to ensure order is preserved and Thanks & Regards Vipin MV

2 1