From mchung at openjdk.java.net Tue Dec 1 00:28:12 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 00:28:12 GMT Subject: RFR: 8230501: Class data support for hidden classes [v7] In-Reply-To: References: Message-ID: > Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects > be shared between a hidden class and other classes. A hidden class can load > these live objects as dynamically-computed constants via this API. > > Specdiff > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html > > With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass` > will be deprecated for removal. Existing libraries should replace their > calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass` > or `Lookup::defineHiddenClassWithClassData`. > > This patch also updates the implementation of lambda meta factory and > `MemoryAccessVarHandleGenerator` to use class data. No performance difference > observed in the jdk.incubator.foreign microbenchmarks. A side note: > `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of > JDK-8254162 but it helps validating the class data support. > > Background > ---------- > > This is an enhancement following up JEP 371: Hidden Classes w.r.t. > "Constant-pool patching" in the "Risks and Assumption" section. > > A VM-anonymous class can be defined with its constant-pool entries already > resolved to concrete values. This allows critical constants to be shared > between a VM-anonymous class and the language runtime that defines it, and > between multiple VM-anonymous classes. For example, a language runtime will > often have `MethodHandle` objects in its address space that would be useful > to newly-defined VM-anonymous classes. Instead of the runtime serializing > the objects to constant-pool entries in VM-anonymous classes and then > generating bytecode in those classes to laboriously `ldc` the entries, > the runtime can simply supply `Unsafe::defineAnonymousClass` with references > to its live objects. The relevant constant-pool entries in the newly-defined > VM-anonymous class are pre-linked to those objects, improving performance > and reducing footprint. In addition, this allows VM-anonymous classes to > refer to each other: Constant-pool entries in a class file are based on names. > They thus cannot refer to nameless VM-anonymous classes. A language runtime can, > however, easily track the live Class objects for its VM-anonymous classes and > supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's > constant pool entries to other VM-anonymous classes. > > This extends the hidden classes to allow live objects to be injected > in a hidden class and loaded them via condy. > > Details > ------- > > A new `Lookup::defineHiddenClassWithClassData` API takes additional > `classData` argument compared to `Lookup::defineHiddenClass`. > Class data can be method handles, lookup objects, arbitrary user objects > or collections of all of the above. > > This method behaves as if calling `Lookup::defineHiddenClass` to define > a hidden class with a private static unnamed field that is initialized > with `classData` at the first instruction of the class initializer. > > `MethodHandles::classData(Lookup lookup, String name, Class type)` and > `MethodHandles::classDataAt(Lookup lookup, String name, Class type, int index)` > are the bootstrap methods to load the class data of the given lookup's lookup class. > The hidden class will be initialized when `classData` method is called if > the hidden class has not been initialized. > > For a class data containing more than one single element, libraries can > create their convenience method to load a single live object via condy. > > Frameworks sometimes want to dynamically create a hidden class (HC) and add it > it the lookup class nest and have HC to carry secrets hidden from that nest. > In this case, frameworks should not to use private static finals (in the HCs > they spin) to hold secrets because a nestmate of HC may obtain access to > such a private static final and observe the framework's secret. It should use > condy. In addition, we need to differentiate if a lookup object is created from > the original lookup class or created from teleporting e.g. `Lookup::in` > and `MethodHandles::privateLookupIn`. > > This proposes to add a new `ORIGINAL` bit that is only set if the lookup > object is created by `MethodHandles::lookup` or by bootstrap method invocation. > The operations only apply to a Lookup object with original access are: > - create method handles for caller-sensitve methods > - obtain class data associated with the lookup class > > No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which > ignores the ORIGINAL bit. > > > Compatibility Risks > ------------------- > > `Lookup::lookupModes` includes a new `ORIGINAL` bit. Most lookup operations > ignore this original bit except creating method handles for caller-sensitive methods > that expects the lookup from the original lookup class. Existing code compares > the return value of `lookupModes` to be a fixed value may be impacted. However > existing client has no need to expect a fixed value of lookup modes. > The incompatibility risk of this spec change is low. Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into class-data - clarify lookup modes of the returned Lookup object - slight tweak of api note - Fix revealDirect to check for original access. - Incorporate Paul's feedback - Fix the name passed to condy calling classData - Merge branch 'master' of https://github.com/openjdk/jdk into class-data - add classDataAt and require name be ConstantDescs.DEFAULT_NAME (which indicates no name is needed) - per Jorn's feedback - Merge - ... and 15 more: https://git.openjdk.java.net/jdk/compare/41dbc139...8b3d44ad ------------- Changes: https://git.openjdk.java.net/jdk/pull/1171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=06 Stats: 970 lines in 17 files changed: 834 ins; 27 del; 109 mod Patch: https://git.openjdk.java.net/jdk/pull/1171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171 PR: https://git.openjdk.java.net/jdk/pull/1171 From mchung at openjdk.java.net Tue Dec 1 00:28:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 00:28:14 GMT Subject: Integrated: 8230501: Class data support for hidden classes In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 18:52:10 GMT, Mandy Chung wrote: > Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects > be shared between a hidden class and other classes. A hidden class can load > these live objects as dynamically-computed constants via this API. > > Specdiff > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html > > With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass` > will be deprecated for removal. Existing libraries should replace their > calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass` > or `Lookup::defineHiddenClassWithClassData`. > > This patch also updates the implementation of lambda meta factory and > `MemoryAccessVarHandleGenerator` to use class data. No performance difference > observed in the jdk.incubator.foreign microbenchmarks. A side note: > `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of > JDK-8254162 but it helps validating the class data support. > > Background > ---------- > > This is an enhancement following up JEP 371: Hidden Classes w.r.t. > "Constant-pool patching" in the "Risks and Assumption" section. > > A VM-anonymous class can be defined with its constant-pool entries already > resolved to concrete values. This allows critical constants to be shared > between a VM-anonymous class and the language runtime that defines it, and > between multiple VM-anonymous classes. For example, a language runtime will > often have `MethodHandle` objects in its address space that would be useful > to newly-defined VM-anonymous classes. Instead of the runtime serializing > the objects to constant-pool entries in VM-anonymous classes and then > generating bytecode in those classes to laboriously `ldc` the entries, > the runtime can simply supply `Unsafe::defineAnonymousClass` with references > to its live objects. The relevant constant-pool entries in the newly-defined > VM-anonymous class are pre-linked to those objects, improving performance > and reducing footprint. In addition, this allows VM-anonymous classes to > refer to each other: Constant-pool entries in a class file are based on names. > They thus cannot refer to nameless VM-anonymous classes. A language runtime can, > however, easily track the live Class objects for its VM-anonymous classes and > supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's > constant pool entries to other VM-anonymous classes. > > This extends the hidden classes to allow live objects to be injected > in a hidden class and loaded them via condy. > > Details > ------- > > A new `Lookup::defineHiddenClassWithClassData` API takes additional > `classData` argument compared to `Lookup::defineHiddenClass`. > Class data can be method handles, lookup objects, arbitrary user objects > or collections of all of the above. > > This method behaves as if calling `Lookup::defineHiddenClass` to define > a hidden class with a private static unnamed field that is initialized > with `classData` at the first instruction of the class initializer. > > `MethodHandles::classData(Lookup lookup, String name, Class type)` and > `MethodHandles::classDataAt(Lookup lookup, String name, Class type, int index)` > are the bootstrap methods to load the class data of the given lookup's lookup class. > The hidden class will be initialized when `classData` method is called if > the hidden class has not been initialized. > > For a class data containing more than one single element, libraries can > create their convenience method to load a single live object via condy. > > Frameworks sometimes want to dynamically create a hidden class (HC) and add it > it the lookup class nest and have HC to carry secrets hidden from that nest. > In this case, frameworks should not to use private static finals (in the HCs > they spin) to hold secrets because a nestmate of HC may obtain access to > such a private static final and observe the framework's secret. It should use > condy. In addition, we need to differentiate if a lookup object is created from > the original lookup class or created from teleporting e.g. `Lookup::in` > and `MethodHandles::privateLookupIn`. > > This proposes to add a new `ORIGINAL` bit that is only set if the lookup > object is created by `MethodHandles::lookup` or by bootstrap method invocation. > The operations only apply to a Lookup object with original access are: > - create method handles for caller-sensitve methods > - obtain class data associated with the lookup class > > No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which > ignores the ORIGINAL bit. > > > Compatibility Risks > ------------------- > > `Lookup::lookupModes` includes a new `ORIGINAL` bit. Most lookup operations > ignore this original bit except creating method handles for caller-sensitive methods > that expects the lookup from the original lookup class. Existing code compares > the return value of `lookupModes` to be a fixed value may be impacted. However > existing client has no need to expect a fixed value of lookup modes. > The incompatibility risk of this spec change is low. This pull request has now been integrated. Changeset: 4356469a Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/4356469a Stats: 970 lines in 17 files changed: 834 ins; 27 del; 109 mod 8230501: Class data support for hidden classes Reviewed-by: jvernee, psandoz, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1171 From mchung at openjdk.java.net Tue Dec 1 00:39:55 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 00:39:55 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On Mon, 30 Nov 2020 20:57:32 GMT, Harold Seigel wrote: >> src/java.base/share/classes/java/lang/Class.java line 4480: >> >>> 4478: } >>> 4479: >>> 4480: private native Class[] getPermittedSubclasses0(); >> >> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS: >> >> - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C >> - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C >> >> I didn't check the VM implementation. >> >> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified. > > The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements. It returns all the classes listed in the PermittedSubclasses attribute that it is able to load. So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right? The specification of `Class::getPermittedSubclasses` says: > Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Tue Dec 1 00:55:01 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 00:55:01 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Improving getPermittedSubclasses javadoc. > - Merge branch 'master' into JDK-8246778 > - Moving checkPackageAccess from getPermittedSubclasses to a separate method. > - Improving getPermittedSubclasses() javadoc. > - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules. > - Removing unnecessary file. > - Tweaking javadoc. > - Reflecting review comments w.r.t. narrowing conversion. > - Improving checks in getPermittedSubclasses() > - Merging master into JDK-8246778 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179 test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclassesTest.java line 54: > 52: public static void testSealedInfo(Class c, String[] expected) { > 53: Object[] permitted = c.getPermittedSubclasses(); > 54: Why `permitted` is not `Class[]`? or simply `var permitted = ...` test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclassesTest.java line 69: > 67: for (int i = 0; i < permitted.length; i++) { > 68: permittedNames.add(((Class)permitted[i]).getName()); > 69: } This cast is not needed if `permitted` is `var` or `Class[]` type. test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 3: > 1: /* > 2: * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. the copyright start year should be 2020. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From jjg at openjdk.java.net Tue Dec 1 02:21:02 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 1 Dec 2020 02:21:02 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:27:11 GMT, Jan Lahoda wrote: >> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: >> -updating and moving tests into test/langtools, so that it is easier to run them. >> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). >> -fixing the -Xprint annotation processor to print record component annotations. >> >> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing tests on Windows - normalizing line endings. Looks mostly OK; some minor comments inline. test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 110: > 108: "--add-exports", "jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED", > 109: "--add-exports", "jdk.javadoc/jdk.javadoc.internal.api=ALL-UNNAMED", > 110: "--add-exports", "jdk.javadoc/jdk.javadoc.internal.tool=ALL-UNNAMED", I'm surprised CreateSymbolsTest needs access to javadoc internals; is it because you're adding all of toolbox in lines 93, 94? Would it be better to filter out the classes you don't want to compile, such as `JavadocTask` and `JavapTask` ? test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 54: > 52: import java.util.Enumeration; > 53: import java.util.jar.JarEntry; > 54: import java.util.jar.JarFile; weird order of imports test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 238: > 236: "t.Visible", > 237: "package t;\n\n" + > 238: // "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX Is this line still supposed to be here? test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 270: > 268: "t.Visible", > 269: "package t;\n\n" + > 270: // "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX Is this line still supposed to be here? test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 307: > 305: } > 306: > 307: // @Test XXX Another XXX line test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513: > 511: public java.util.List l(); > 512: } > 513: """, I don't understand why the lines with `\n` in a text block test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 69: > 67: System.err.println("Warning: cannot find CreateSymbols, skipping."); > 68: return ; > 69: } I can believe this test is worth just a warning, because you're trying to reach into the `make` directory, but the subsequent checks for `CreateSymbolsTestImpl.java` and `toolbox.*` seem worthy of errors, not warnings. On the other hand, I accept that all of these checks are very unlikely to fail, so maybe it doesn't matter. test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 30: > 28: * @modules java.compiler > 29: * jdk.compiler > 30: * jdk.javadoc See related comments in code ... seems strange to need `jdk.javadoc`. test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 121: > 119: } > 120: > 121: URLClassLoader cl = new URLClassLoader(new URL[] {testClasses.toUri().toURL(), compileDir.toUri().toURL()}); line 132: the name of the local variable `createSymbols` seems more specific than the method might imply! ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From david.holmes at oracle.com Tue Dec 1 02:40:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 12:40:42 +1000 Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On 1/12/2020 10:39 am, Mandy Chung wrote: > On Mon, 30 Nov 2020 20:57:32 GMT, Harold Seigel wrote: > >>> src/java.base/share/classes/java/lang/Class.java line 4480: >>> >>>> 4478: } >>>> 4479: >>>> 4480: private native Class[] getPermittedSubclasses0(); >>> >>> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS: >>> >>> - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C >>> - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C >>> >>> I didn't check the VM implementation. >>> >>> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified. >> >> The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements. It returns all the classes listed in the PermittedSubclasses attribute that it is able to load. > > So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right? > > The specification of `Class::getPermittedSubclasses` says: > >> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. > > I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime. These subtleties are what I was also getting at in the CSR discussion. If Foo lists Bar as a permitted subtype, but Bar does not extend Foo, is that an error? Should Bar not be returned by getPermittedSubclasses? The answer depends on exactly how you specify getPermittedSubclasses() and whether that aligns with reading the classfile attribute, or actually checking the runtime relationships. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1483 > From plevart at openjdk.java.net Tue Dec 1 09:36:00 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 1 Dec 2020 09:36:00 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better In-Reply-To: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote: > Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. > > Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked. > > Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. > > Testing: > - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049) > - tier1-4 src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1760: > 1758: > 1759: private volatile boolean updateInProgress = false; > 1760: Hi (line 1759): redundant initialization of volatile field to default value is not needed or desired. ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From plevart at openjdk.java.net Tue Dec 1 10:07:56 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 1 Dec 2020 10:07:56 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better In-Reply-To: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote: > Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. > > Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked. > > Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. > > Testing: > - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049) > - tier1-4 src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1783: > 1781: } finally { > 1782: updateInProgress = false; > 1783: } Line 1782. I understand that in case the try block fails to update `form` field, resetting `updateInProgress` is desirable in order for next caller to attempt to update the form next time, but in case (the majority case) the try block successfully updates the `form` field, resetting the `updateInProgress` back to `false` opens a theoretical window (very improbable) for a concurrent thread to re-execute the updater function at least. Perhaps you could write `catch (Throwable e)` instead of `finally` and only in case of failure, reset the `updateInProgress` field and re-throw the exception. WDYT? It is also very strange that the code is updating a final `form` field using Unsafe. Is this only to ensure that reads of that field scattered around in code are accompanied with a suitable read fence if needed (on some architectures)? How does this work considering (I may be wrong, but I think I heard) that VM trusts final fields in java.lang.invoke package. ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Dec 1 10:51:16 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 1 Dec 2020 10:51:16 GMT Subject: RFR: JDK-8249836 java/io/IOException/LastErrorString.java should have bug-id as 1st word in @ignore [v2] In-Reply-To: References: Message-ID: > ?id as 1st word in @ignore > > https://bugs.openjdk.java.net/browse/JDK-8249836 Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision: - /integrate Merge branch 'JDK-8249836' of https://github.com/mahendrachhipa/jdk into JDK-8249836 - /integrate JDK-8249836 ava/io/IOException/LastErrorString.java should have bug-id as 1st word in @ignore https://bugs.openjdk.java.net/browse/JDK-8249836 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1482/files - new: https://git.openjdk.java.net/jdk/pull/1482/files/7ded2a76..d744ec08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1482&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1482&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1482/head:pull/1482 PR: https://git.openjdk.java.net/jdk/pull/1482 From jlahoda at openjdk.java.net Tue Dec 1 11:18:11 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Dec 2020 11:18:11 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v4] In-Reply-To: References: Message-ID: > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1480/files - new: https://git.openjdk.java.net/jdk/pull/1480/files/a3f79aba..9ab7153a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=02-03 Stats: 28 lines in 2 files changed: 5 ins; 11 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480 From dfuchs at openjdk.java.net Tue Dec 1 11:34:05 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 1 Dec 2020 11:34:05 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v12] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 20:56:17 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F. > Added a test to verify isHexDigit and fromHexDigit for the entire range of chars src/java.base/share/classes/java/lang/Integer.java line 265: > 263: * of byte arrays and primitives to return a string or adding to an {@link Appendable}. > 264: * HexFormat formats and parses uppercase or lowercase hexadecimal characters, > 265: * with leading zeros and for byte arrays includes for each byte Should that be: * {@code HexFormat} formats and parses uppercase or lowercase hexadecimal characters, or * The {@code HexFormat} class formats and parses uppercase or lowercase hexadecimal characters, src/java.base/share/classes/java/lang/Long.java line 299: > 297: * {@link java.util.HexFormat} provides formatting and parsing > 298: * of byte arrays and primitives to return a string or adding to an {@link Appendable}. > 299: * HexFormat formats and parses uppercase or lowercase hexadecimal characters, Same remark here: `{@code HexFormat}` src/java.base/share/classes/java/util/HexFormat.java line 171: > 169: new HexFormat("", "", "", LOWERCASE_DIGITS); > 170: > 171: private static final byte[] emptyBytes = new byte[0]; Nit: I believe it might be clearer (at the point of use) if that constant name was all upper case - as it would be more obvious that what is used there is a static final constant. e.g. if the name was something like EMPTY_BYTES or NO_BYTES then when it's later used in the code it would be clearer that a constant is being referenced. src/java.base/share/classes/java/util/HexFormat.java line 347: > 345: if (s == null) { > 346: StringBuilder sb = new StringBuilder((toIndex - fromIndex) * > 347: (delimiter.length() + prefix.length() + 2 + suffix.length()) - delimiter.length()); There should be some guard here that this length computation does not overflow. And also a test to verify that this is handled properly? src/java.base/share/classes/java/util/HexFormat.java line 362: > 360: * > 361: * @param The type of Appendable > 362: * @param out an Appendable, non-null should be {@code Appendable} on both lines src/java.base/share/classes/java/util/HexFormat.java line 379: > 377: * > 378: * @param The type of Appendable > 379: * @param out an Appendable, non-null should be `{@code Appendable}` on both lines src/java.base/share/classes/java/util/HexFormat.java line 436: > 434: if (delimiter.isEmpty()) { > 435: // Allocate the byte array and fill in the hex pairs for each byte > 436: rep = new byte[length * 2]; What if `length * 2` overflows? src/java.base/share/classes/java/util/HexFormat.java line 445: > 443: // Then insert the delimiter and hexadecimal characters for each of the remaining bytes > 444: char sep = delimiter.charAt(0); > 445: rep = new byte[length * 3 - 1]; same here: what if `length * 3 - 1` overflows? src/java.base/share/classes/java/util/HexFormat.java line 516: > 514: > 515: int valueChars = prefix.length() + 2 + suffix.length(); > 516: int stride = valueChars + delimiter.length(); Unlikely - but there's still a possibility of overflow in these two lines? I wonder if those should be checked at construction time - and an IAE thrown if someone tried to create a HexFormat with unreasonable prefix/suffix/delimiters? Otherwise maybe use Math.addExact()... src/java.base/share/classes/java/util/HexFormat.java line 660: > 658: * > 659: * @param The type of Appendable > 660: * @param out an Appendable, non-null Should be `{@code Appendable}` on both lines src/java.base/share/classes/java/util/HexFormat.java line 741: > 739: /** > 740: * Returns the sixteen hexadecimal characters for the {@code long} value > 741: * considering it to be unsigned. What does this means? And why is it necessary for long when it wasn't necessary for other signed types (byte, short, int). I'd vote for removing `considering it to be unsigned` there - or else add it everywhere else, but then you would have to explain what it means and what you would print if you considered it signed. src/java.base/share/classes/java/util/HexFormat.java line 887: > 885: * The characters in the range from {@code index} to {@code index + 1}, > 886: * inclusive, must be valid hex digits according to {@link #fromHexDigit(int)}. > 887: * The delimiter, prefix and suffix are not used. In this method - and all similar methods that follow - then is `isUpperCase()` taken into account? If not maybe it should be made explicit - just as for delimiter, prefix, and suffix? Alternatively, remove this line and make the method static. Then it would be clear that upperCase, delimiter, prefix, and suffix are not used. ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From dfuchs at openjdk.java.net Tue Dec 1 11:34:06 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 1 Dec 2020 11:34:06 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v10] In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 17:01:35 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/util/HexFormat.java line 528: >> >>> 526: * a range of the character array. >>> 527: * >>> 528: * Each byte value is parsed as the prefix, two case insensitive hexadecimal characters, >> >> Each *char* value ... > > The value being parsed is a byte, constructed from the input consisting of prefix, two hex characters, and the suffix. I am not a native English speaker, but I thought what was parsed is a string - or in this case a `char` array - in order to obtain a `byte` array; So maybe `Each byte value is computed by parsing a prefix, ...` or something along those lines? Or maybe simply `Each byte value is parsed *from* a prefix, ...` Feel free to disregard if I'm mistaken. ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From alanb at openjdk.java.net Tue Dec 1 11:42:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Dec 2020 11:42:58 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v8] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 20:55:19 GMT, Mandy Chung wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with the proxy class as the caller, equivalent to calling >> `X.super::m` where `X` is a proxy interface of the proxy class and >> `X.super::m` will resolve to the specified default method. >> >> The implementation will call a private static `proxyClassLookup(Lookup caller)` >> method of the proxy class to obtain its private Lookup. This private method >> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class >> with full privilege access to use, or else `IllegalAccessException` will be >> thrown. >> >> This patch also proposes to define a proxy class in an unnamed module to >> a dynamic module to strengthen encapsulation such that they are only >> unconditionally exported from a named module but not open for deep reflective >> access. This only applies to the case if all the proxy interfaces are public >> and in a package that is exported or open. >> >> One dynamic module is created for each class loader that defines proxies. >> The change changes the dynamic module to contain another package (same >> name as the module) that is unconditionally exported and is opened to >> `java.base` only. >> >> There is no change to the package and module of the proxy class for >> the following cases: >> >> - if at least one proxy interface is non-public, then the proxy class is defined >> in the package and module of the non-public interfaces >> - if at least one proxy is in a package that is non-exported and non-open, >> if all proxy interfaces are public, then the proxy class is defined in >> a non-exported, non-open package of a dynamic module. >> >> The spec change is that a proxy class used to be defined in an unnamed >> module, i.e. in a exported and open package, is defined in an unconditionally >> exported but non-open package. Programs that assume it to be open unconditionally >> will be affected and cannot do deep reflection on such proxy classes. >> >> Peter Levart contributed an initial prototype [1] (thanks Peter). I think >> the exceptions could be simplified as more checking should be done prior to >> the invocation of the method handle like checking the types of the arguments >> with the method type. This approach avoids defining a public API >> `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a >> private static method that is restricted for Proxy class to use (by >> taking a caller parameter to ensure it's a private lookup on Proxy class). >> >> javadoc/specdiff: >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments per Alan's feedback Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From jlahoda at openjdk.java.net Tue Dec 1 12:08:58 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Dec 2020 12:08:58 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:43:47 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing tests on Windows - normalizing line endings. > > test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513: > >> 511: public java.util.List l(); >> 512: } >> 513: """, > > I don't understand why the lines with `\n` in a text block There is a combination of factors here: -jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks -textblocks only remove indentation that is common on all lines. So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list): -do some trick to have the common indent, but no trailing whitespace. '\n' is one of them. -not indent the text block -do some post-processing on the text block's value or the actual test output, to make them match -not use textblocks ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From jlahoda at openjdk.java.net Tue Dec 1 12:13:56 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Dec 2020 12:13:56 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 02:18:18 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing tests on Windows - normalizing line endings. > > Looks mostly OK; some minor comments inline. Thanks for the comments Jon! I've tried to resolve them here: https://github.com/openjdk/jdk/pull/1480/commits/9ab7153a4f301dc77c02dd1ffda247cf7cdeb5ea ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From chegar at openjdk.java.net Tue Dec 1 12:35:58 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 1 Dec 2020 12:35:58 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v4] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 11:18:11 GMT, Jan Lahoda wrote: >> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: >> -updating and moving tests into test/langtools, so that it is easier to run them. >> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). >> -fixing the -Xprint annotation processor to print record component annotations. >> >> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Dec 1 12:59:56 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 1 Dec 2020 12:59:56 GMT Subject: Integrated: JDK-8249836 java/io/IOException/LastErrorString.java should have bug-id as 1st word in @ignore In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 16:11:54 GMT, Mahendra Chhipa wrote: > ?id as 1st word in @ignore > > https://bugs.openjdk.java.net/browse/JDK-8249836 This pull request has now been integrated. Changeset: c859fb02 Author: Mahendra Chhipa Committer: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/c859fb02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8249836: java/io/IOException/LastErrorString.java should have bug-id as 1st word in @ignore Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/1482 From redestad at openjdk.java.net Tue Dec 1 14:52:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 1 Dec 2020 14:52:59 GMT Subject: RFR: 8257511: JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) Message-ID: This patch fixes a place where we failed to adjust properly for getBytes taking a length rather than end offset. (Something the public API in AbstractStringBuilder is apparently inconsistent about..) Although this was caught by JCK testing, this patch adds a few trivial sanity tests to get at least some sanity checking into tier1 ------------- Commit messages: - Adjust for inconsistent API.. - JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) Changes: https://git.openjdk.java.net/jdk/pull/1541/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1541&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257511 Stats: 25 lines in 2 files changed: 16 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1541.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1541/head:pull/1541 PR: https://git.openjdk.java.net/jdk/pull/1541 From isipka at openjdk.java.net Tue Dec 1 15:02:09 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Tue, 1 Dec 2020 15:02:09 GMT Subject: RFR: 8256894: define test groups [v2] In-Reply-To: References: Message-ID: > Defined new test groups as defined in ticket. @fguallini Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8257516: removing trailing space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1416/files - new: https://git.openjdk.java.net/jdk/pull/1416/files/6a7ad036..c91558be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1416&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1416&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1416/head:pull/1416 PR: https://git.openjdk.java.net/jdk/pull/1416 From mchung at openjdk.java.net Tue Dec 1 15:37:00 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 15:37:00 GMT Subject: RFR: 8253751: Dependencies of automatic modules are not propagated through module layers [v2] In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 09:38:15 GMT, Alan Bateman wrote: >> This is a corner case that arises when creating a Configuration for a child module layer. If an explicit module in the child configuration reads an automatic module in a parent configuration then it should read all automatic modules in the parent configurations. Unfortunately, this read edge wasn't created for the case that the child layer does not contain any automatic modules. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Formatting nit > - Merge > - Merge > - Merge > - Add @bug to test > - Fixed typo in comment > - Merge > - Merge > - If module reads automatic module in parent configuration then reads all automatic modules Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1391 From alanb at openjdk.java.net Tue Dec 1 15:43:00 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Dec 2020 15:43:00 GMT Subject: Integrated: 8253751: Dependencies of automatic modules are not propagated through module layers In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 15:27:52 GMT, Alan Bateman wrote: > This is a corner case that arises when creating a Configuration for a child module layer. If an explicit module in the child configuration reads an automatic module in a parent configuration then it should read all automatic modules in the parent configurations. Unfortunately, this read edge wasn't created for the case that the child layer does not contain any automatic modules. This pull request has now been integrated. Changeset: 1433bafb Author: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/1433bafb Stats: 85 lines in 2 files changed: 75 ins; 5 del; 5 mod 8253751: Dependencies of automatic modules are not propagated through module layers Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/1391 From plevart at openjdk.java.net Tue Dec 1 15:48:58 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 1 Dec 2020 15:48:58 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: On Tue, 1 Dec 2020 10:05:04 GMT, Peter Levart wrote: >> Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. >> >> Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked. >> >> Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. >> >> Testing: >> - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049) >> - tier1-4 > > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1783: > >> 1781: } finally { >> 1782: updateInProgress = false; >> 1783: } > > Line 1782. I understand that in case the try block fails to update `form` field, resetting `updateInProgress` is desirable in order for next caller to attempt to update the form next time, but in case (the majority case) the try block successfully updates the `form` field, resetting the `updateInProgress` back to `false` opens a theoretical window (very improbable) for a concurrent thread to re-execute the updater function at least. Perhaps you could write `catch (Throwable e)` instead of `finally` and only in case of failure, reset the `updateInProgress` field and re-throw the exception. WDYT? > > It is also very strange that the code is updating a final `form` field using Unsafe. Is this only to ensure that reads of that field scattered around in code are accompanied with a suitable read fence if needed (on some architectures)? How does this work considering (I may be wrong, but I think I heard) that VM trusts final fields in java.lang.invoke package. It seems that I was right. See `ciField.cpp`: static bool trust_final_non_static_fields(ciInstanceKlass* holder) { if (holder == NULL) return false; if (holder->name() == ciSymbol::java_lang_System()) // Never trust strangely unstable finals: System.out, etc. return false; // Even if general trusting is disabled, trust system-built closures in these packages. if (holder->is_in_package("java/lang/invoke") || holder->is_in_package("sun/invoke") || holder->is_in_package("jdk/internal/foreign") || holder->is_in_package("jdk/incubator/foreign") || holder->is_in_package("jdk/internal/vm/vector") || holder->is_in_package("jdk/incubator/vector") || holder->is_in_package("java/lang")) return true; ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From plevart at openjdk.java.net Tue Dec 1 15:57:58 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 1 Dec 2020 15:57:58 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> On Tue, 1 Dec 2020 15:45:45 GMT, Peter Levart wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1783: >> >>> 1781: } finally { >>> 1782: updateInProgress = false; >>> 1783: } >> >> Line 1782. I understand that in case the try block fails to update `form` field, resetting `updateInProgress` is desirable in order for next caller to attempt to update the form next time, but in case (the majority case) the try block successfully updates the `form` field, resetting the `updateInProgress` back to `false` opens a theoretical window (very improbable) for a concurrent thread to re-execute the updater function at least. Perhaps you could write `catch (Throwable e)` instead of `finally` and only in case of failure, reset the `updateInProgress` field and re-throw the exception. WDYT? >> >> It is also very strange that the code is updating a final `form` field using Unsafe. Is this only to ensure that reads of that field scattered around in code are accompanied with a suitable read fence if needed (on some architectures)? How does this work considering (I may be wrong, but I think I heard) that VM trusts final fields in java.lang.invoke package. > > It seems that I was right. See `ciField.cpp`: > > static bool trust_final_non_static_fields(ciInstanceKlass* holder) { > if (holder == NULL) > return false; > if (holder->name() == ciSymbol::java_lang_System()) > // Never trust strangely unstable finals: System.out, etc. > return false; > // Even if general trusting is disabled, trust system-built closures in these packages. > if (holder->is_in_package("java/lang/invoke") || holder->is_in_package("sun/invoke") || > holder->is_in_package("jdk/internal/foreign") || holder->is_in_package("jdk/incubator/foreign") || > holder->is_in_package("jdk/internal/vm/vector") || holder->is_in_package("jdk/incubator/vector") || > holder->is_in_package("java/lang")) > return true; I mean, is it possible that some threads that concurrently use the old uncustomized form while one thread is customizing it, trigger JIT compilation and because `form` field is trusted final, the JITed code will be using the uncustomized form for ever. Even after the customization thread plants the new form... This was possible before, but maybe the probability is greater after this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From alanb at openjdk.java.net Tue Dec 1 16:08:56 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Dec 2020 16:08:56 GMT Subject: RFR: 8257511: JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:49:01 GMT, Claes Redestad wrote: > This patch fixes a place where we failed to adjust properly for getBytes taking a length rather than end offset. (Something the public API in AbstractStringBuilder is apparently inconsistent about..) > > Although this was caught by JCK testing, this patch adds a few trivial sanity tests to get at least some sanity checking into tier1 Marked as reviewed by alanb (Reviewer). test/jdk/java/lang/StringBuilder/Insert.java line 45: > 43: public void insertOffset() { > 44: // 8254082 made the String variant cause an AIOOBE, fixed in 8257511 > 45: assertEquals("efabc", new StringBuilder("abc").insert(0, "def", 1, 3).toString()); The change looks okay. Changing this test, and converting to TestNG is okay too. I guess I wouldn't try to align the start, end on L45 as it doesn't really help readability (doesn't matter of course). ------------- PR: https://git.openjdk.java.net/jdk/pull/1541 From rriggs at openjdk.java.net Tue Dec 1 16:11:04 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Dec 2020 16:11:04 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v12] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 10:37:40 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F. >> Added a test to verify isHexDigit and fromHexDigit for the entire range of chars > > src/java.base/share/classes/java/util/HexFormat.java line 436: > >> 434: if (delimiter.isEmpty()) { >> 435: // Allocate the byte array and fill in the hex pairs for each byte >> 436: rep = new byte[length * 2]; > > What if `length * 2` overflows? It should produce an OOME, at the moment would throw NegativeArraySize. Same below, will add an explicit check and throw. > src/java.base/share/classes/java/util/HexFormat.java line 516: > >> 514: >> 515: int valueChars = prefix.length() + 2 + suffix.length(); >> 516: int stride = valueChars + delimiter.length(); > > Unlikely - but there's still a possibility of overflow in these two lines? > I wonder if those should be checked at construction time - and an IAE thrown if someone tried to create a HexFormat with unreasonable prefix/suffix/delimiters? > Otherwise maybe use Math.addExact()... Using long for the intermediate results will avoid the issue. With maximum prefix or suffix and maximum length string, one of the exceptions for length or missing prefix or suffix would throw. The computation for the output byte array can revert to int after the divide by stride. > src/java.base/share/classes/java/util/HexFormat.java line 741: > >> 739: /** >> 740: * Returns the sixteen hexadecimal characters for the {@code long} value >> 741: * considering it to be unsigned. > > What does this means? And why is it necessary for long when it wasn't necessary for other signed types (byte, short, int). I'd vote for removing `considering it to be unsigned` there - or else add it everywhere else, but then you would have to explain what it means and what you would print if you considered it signed. Will remove. All java primitive types are signed. When formatted, there is no representation of the sign. ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From plevart at openjdk.java.net Tue Dec 1 16:16:58 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 1 Dec 2020 16:16:58 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v8] In-Reply-To: References: Message-ID: <88eo20LwITdp__3viOErd57QmwThwyy3cS2-mQHtUaI=.c6990687-d4af-49e3-8978-50560259e99c@github.com> On Mon, 30 Nov 2020 20:55:19 GMT, Mandy Chung wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with the proxy class as the caller, equivalent to calling >> `X.super::m` where `X` is a proxy interface of the proxy class and >> `X.super::m` will resolve to the specified default method. >> >> The implementation will call a private static `proxyClassLookup(Lookup caller)` >> method of the proxy class to obtain its private Lookup. This private method >> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class >> with full privilege access to use, or else `IllegalAccessException` will be >> thrown. >> >> This patch also proposes to define a proxy class in an unnamed module to >> a dynamic module to strengthen encapsulation such that they are only >> unconditionally exported from a named module but not open for deep reflective >> access. This only applies to the case if all the proxy interfaces are public >> and in a package that is exported or open. >> >> One dynamic module is created for each class loader that defines proxies. >> The change changes the dynamic module to contain another package (same >> name as the module) that is unconditionally exported and is opened to >> `java.base` only. >> >> There is no change to the package and module of the proxy class for >> the following cases: >> >> - if at least one proxy interface is non-public, then the proxy class is defined >> in the package and module of the non-public interfaces >> - if at least one proxy is in a package that is non-exported and non-open, >> if all proxy interfaces are public, then the proxy class is defined in >> a non-exported, non-open package of a dynamic module. >> >> The spec change is that a proxy class used to be defined in an unnamed >> module, i.e. in a exported and open package, is defined in an unconditionally >> exported but non-open package. Programs that assume it to be open unconditionally >> will be affected and cannot do deep reflection on such proxy classes. >> >> Peter Levart contributed an initial prototype [1] (thanks Peter). I think >> the exceptions could be simplified as more checking should be done prior to >> the invocation of the method handle like checking the types of the arguments >> with the method type. This approach avoids defining a public API >> `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a >> private static method that is restricted for Proxy class to use (by >> taking a caller parameter to ensure it's a private lookup on Proxy class). >> >> javadoc/specdiff: >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments per Alan's feedback I looked again at the code and it seems good. ------------- Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/313 From jlahoda at openjdk.java.net Tue Dec 1 16:51:56 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Dec 2020 16:51:56 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On Tue, 1 Dec 2020 00:36:54 GMT, Mandy Chung wrote: >> The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements. It returns all the classes listed in the PermittedSubclasses attribute that it is able to load. > > So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right? > > The specification of `Class::getPermittedSubclasses` says: > >> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. > > I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime. I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module). Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included. So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class. My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). [1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5 ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Tue Dec 1 17:19:42 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 17:19:42 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v9] In-Reply-To: References: Message-ID: > This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling > `X.super::m` where `X` is a proxy interface of the proxy class and > `X.super::m` will resolve to the specified default method. > > The implementation will call a private static `proxyClassLookup(Lookup caller)` > method of the proxy class to obtain its private Lookup. This private method > in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class > with full privilege access to use, or else `IllegalAccessException` will be > thrown. > > This patch also proposes to define a proxy class in an unnamed module to > a dynamic module to strengthen encapsulation such that they are only > unconditionally exported from a named module but not open for deep reflective > access. This only applies to the case if all the proxy interfaces are public > and in a package that is exported or open. > > One dynamic module is created for each class loader that defines proxies. > The change changes the dynamic module to contain another package (same > name as the module) that is unconditionally exported and is opened to > `java.base` only. > > There is no change to the package and module of the proxy class for > the following cases: > > - if at least one proxy interface is non-public, then the proxy class is defined > in the package and module of the non-public interfaces > - if at least one proxy is in a package that is non-exported and non-open, > if all proxy interfaces are public, then the proxy class is defined in > a non-exported, non-open package of a dynamic module. > > The spec change is that a proxy class used to be defined in an unnamed > module, i.e. in a exported and open package, is defined in an unconditionally > exported but non-open package. Programs that assume it to be open unconditionally > will be affected and cannot do deep reflection on such proxy classes. > > Peter Levart contributed an initial prototype [1] (thanks Peter). I think > the exceptions could be simplified as more checking should be done prior to > the invocation of the method handle like checking the types of the arguments > with the method type. This approach avoids defining a public API > `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a > private static method that is restricted for Proxy class to use (by > taking a caller parameter to ensure it's a private lookup on Proxy class). > > javadoc/specdiff: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 28 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - Improve comments per Alan's feedback - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - update copyright header - clean up DefaultMethodProxy test - Performance improvement contributed by plevart - Clean up the patch. Rename to - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails - ... and 18 more: https://git.openjdk.java.net/jdk/compare/820cff1d...892fed79 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/313/files - new: https://git.openjdk.java.net/jdk/pull/313/files/bb23cfa8..892fed79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=07-08 Stats: 15416 lines in 406 files changed: 10401 ins; 2808 del; 2207 mod Patch: https://git.openjdk.java.net/jdk/pull/313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313 PR: https://git.openjdk.java.net/jdk/pull/313 From mchung at openjdk.java.net Tue Dec 1 17:25:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 17:25:56 GMT Subject: Integrated: 8159746: (proxy) Support for default methods In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 22:38:04 GMT, Mandy Chung wrote: > This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling > `X.super::m` where `X` is a proxy interface of the proxy class and > `X.super::m` will resolve to the specified default method. > > The implementation will call a private static `proxyClassLookup(Lookup caller)` > method of the proxy class to obtain its private Lookup. This private method > in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class > with full privilege access to use, or else `IllegalAccessException` will be > thrown. > > This patch also proposes to define a proxy class in an unnamed module to > a dynamic module to strengthen encapsulation such that they are only > unconditionally exported from a named module but not open for deep reflective > access. This only applies to the case if all the proxy interfaces are public > and in a package that is exported or open. > > One dynamic module is created for each class loader that defines proxies. > The change changes the dynamic module to contain another package (same > name as the module) that is unconditionally exported and is opened to > `java.base` only. > > There is no change to the package and module of the proxy class for > the following cases: > > - if at least one proxy interface is non-public, then the proxy class is defined > in the package and module of the non-public interfaces > - if at least one proxy is in a package that is non-exported and non-open, > if all proxy interfaces are public, then the proxy class is defined in > a non-exported, non-open package of a dynamic module. > > The spec change is that a proxy class used to be defined in an unnamed > module, i.e. in a exported and open package, is defined in an unconditionally > exported but non-open package. Programs that assume it to be open unconditionally > will be affected and cannot do deep reflection on such proxy classes. > > Peter Levart contributed an initial prototype [1] (thanks Peter). I think > the exceptions could be simplified as more checking should be done prior to > the invocation of the method handle like checking the types of the arguments > with the method type. This approach avoids defining a public API > `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a > private static method that is restricted for Proxy class to use (by > taking a caller parameter to ensure it's a private lookup on Proxy class). > > javadoc/specdiff: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html This pull request has now been integrated. Changeset: 56b15fbb Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/56b15fbb Stats: 1420 lines in 29 files changed: 1276 ins; 44 del; 100 mod 8159746: (proxy) Support for default methods Co-authored-by: Peter Levart Reviewed-by: darcy, alanb, plevart ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From bpb at openjdk.java.net Tue Dec 1 17:29:10 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 1 Dec 2020 17:29:10 GMT Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v4] In-Reply-To: References: Message-ID: <1swUGstQk9qwUOvShQK1dbyk__17hTBWRTSYjDPmIM0=.74834919-9922-49e7-a6ff-c081878f41cf@github.com> > Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8246739: InputStream.skipNBytes could be implemented more efficiently ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1329/files - new: https://git.openjdk.java.net/jdk/pull/1329/files/60fe0953..31678bfa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1329.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1329/head:pull/1329 PR: https://git.openjdk.java.net/jdk/pull/1329 From ccheung at openjdk.java.net Tue Dec 1 19:38:01 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 19:38:01 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes Message-ID: Please review this change which includes: - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. Testing: - [x] all cds/appcds tests locally on linux-x64 - [x] tiers 1 - 4 (in progress) ------------- Commit messages: - 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes Changes: https://git.openjdk.java.net/jdk/pull/1542/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257241 Stats: 52 lines in 7 files changed: 2 ins; 11 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From chegar at openjdk.java.net Tue Dec 1 19:39:08 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 1 Dec 2020 19:39:08 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract Message-ID: Update Class::isRecord to only return true for classes that are final. The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: 1. It is a compile-time error if a record declaration has the modifier abstract. 2. A record declaration is implicitly final. 3. The direct superclass type of a record class is Record. Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. ------------- Commit messages: - Initial changes for 8255560 Changes: https://git.openjdk.java.net/jdk/pull/1543/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255560 Stats: 241 lines in 5 files changed: 209 ins; 12 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1543/head:pull/1543 PR: https://git.openjdk.java.net/jdk/pull/1543 From rriggs at openjdk.java.net Tue Dec 1 19:43:55 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Dec 2020 19:43:55 GMT Subject: RFR: 8257511: JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) In-Reply-To: References: Message-ID: <3pxRuf7AnBBDVAPnv_o4ZPUeSK6RZHOpOZalBA7Suh4=.6665133c-6627-4f8e-851f-ac82ddff7f83@github.com> On Tue, 1 Dec 2020 14:49:01 GMT, Claes Redestad wrote: > This patch fixes a place where we failed to adjust properly for getBytes taking a length rather than end offset. (Something the public API in AbstractStringBuilder is apparently inconsistent about..) > > Although this was caught by JCK testing, this patch adds a few trivial sanity tests to get at least some sanity checking into tier1 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1541 From mchung at openjdk.java.net Tue Dec 1 19:54:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 19:54:57 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:34:11 GMT, Chris Hegarty wrote: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. test/jdk/java/lang/reflect/records/IsRecordTest.java line 138: > 136: record EmptyRecord () { } > 137: assertTrue(EmptyRecord.class.isRecord()); > 138: assertTrue(EmptyRecord.class.getRecordComponents() != null); Better to have a more precise check for empty array ------------- PR: https://git.openjdk.java.net/jdk/pull/1543 From mchung at openjdk.java.net Tue Dec 1 20:01:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 20:01:57 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract In-Reply-To: References: Message-ID: <9ptQ8cI5ab3ACMrc7Hxnoup93E_1fZbiLbjEK50oHmo=.bdbc442f-70ca-4b24-9588-d84b7ce2883f@github.com> On Tue, 1 Dec 2020 19:34:11 GMT, Chris Hegarty wrote: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. The change looks good with a couple of minor suggestion. src/java.base/share/classes/java/lang/Class.java line 3668: > 3666: *

The {@linkplain #getSuperclass() direct superclass} of a record > 3667: * class is {@code java.lang.Record}. A record class is > 3668: * {@link Modifier#FINAL}. A record class has (possibly zero) record nit: `{@linkplain Modifier#FINAL final}`. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1543 From mchung at openjdk.java.net Tue Dec 1 20:05:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 20:05:57 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) The change looks okay. Can you add a test to verify that it won't load from CDS archive if `disableEagerInitialization` is true? ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From bpb at openjdk.java.net Tue Dec 1 20:10:57 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 1 Dec 2020 20:10:57 GMT Subject: Integrated: 8246739: InputStream.skipNBytes could be implemented more efficiently In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 19:29:43 GMT, Brian Burkhalter wrote: > Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant. This pull request has now been integrated. Changeset: c5046ca5 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/c5046ca5 Stats: 20 lines in 1 file changed: 4 ins; 3 del; 13 mod 8246739: InputStream.skipNBytes could be implemented more efficiently Reviewed-by: rriggs, lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/1329 From chegar at openjdk.java.net Tue Dec 1 20:13:14 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 1 Dec 2020 20:13:14 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v2] In-Reply-To: References: Message-ID: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Mandy's review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1543/files - new: https://git.openjdk.java.net/jdk/pull/1543/files/3b3e42c5..d626eeed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1543/head:pull/1543 PR: https://git.openjdk.java.net/jdk/pull/1543 From chegar at openjdk.java.net Tue Dec 1 20:13:16 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 1 Dec 2020 20:13:16 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v2] In-Reply-To: <9ptQ8cI5ab3ACMrc7Hxnoup93E_1fZbiLbjEK50oHmo=.bdbc442f-70ca-4b24-9588-d84b7ce2883f@github.com> References: <9ptQ8cI5ab3ACMrc7Hxnoup93E_1fZbiLbjEK50oHmo=.bdbc442f-70ca-4b24-9588-d84b7ce2883f@github.com> Message-ID: <-vWAHSMmNQx0bL2tb_JtyxU7BbFWB4Mffy6R0hj4bmg=.5cd66077-0600-4b5a-916f-f1f643796ca2@github.com> On Tue, 1 Dec 2020 19:56:25 GMT, Mandy Chung wrote: >> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: >> >> Mandy's review comments > > src/java.base/share/classes/java/lang/Class.java line 3668: > >> 3666: *

The {@linkplain #getSuperclass() direct superclass} of a record >> 3667: * class is {@code java.lang.Record}. A record class is >> 3668: * {@link Modifier#FINAL}. A record class has (possibly zero) record > > nit: `{@linkplain Modifier#FINAL final}`. Good idea - done. > test/jdk/java/lang/reflect/records/IsRecordTest.java line 138: > >> 136: record EmptyRecord () { } >> 137: assertTrue(EmptyRecord.class.isRecord()); >> 138: assertTrue(EmptyRecord.class.getRecordComponents() != null); > > Better to have a more precise check for empty array Good idea - done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1543 From iklam at openjdk.java.net Tue Dec 1 20:21:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 20:21:55 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) LGTM. I agree with Mandy that we need a test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From psandoz at openjdk.java.net Tue Dec 1 20:43:04 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 1 Dec 2020 20:43:04 GMT Subject: RFR: 8257537: [vector] Cleanup redundant bitwise cases on floating point vectors Message-ID: Float/DoubleVector implementations contain redundant cases for bitwise operations. Such bitwise operations will fail on such FP vectors before the case is reached. ------------- Commit messages: - 8257537: [vector] Cleanup redundant bitwise cases on floating point vectors Changes: https://git.openjdk.java.net/jdk/pull/1544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1544&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257537 Stats: 28 lines in 3 files changed: 4 ins; 24 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1544/head:pull/1544 PR: https://git.openjdk.java.net/jdk/pull/1544 From redestad at openjdk.java.net Tue Dec 1 20:52:54 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 1 Dec 2020 20:52:54 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Looks good to me! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1542 From bpb at openjdk.java.net Tue Dec 1 20:58:56 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 1 Dec 2020 20:58:56 GMT Subject: RFR: 8257511: JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:49:01 GMT, Claes Redestad wrote: > This patch fixes a place where we failed to adjust properly for getBytes taking a length rather than end offset. (Something the public API in AbstractStringBuilder is apparently inconsistent about..) > > Although this was caught by JCK testing, this patch adds a few trivial sanity tests to get at least some sanity checking into tier1 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1541 From mchung at openjdk.java.net Tue Dec 1 21:06:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 21:06:58 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:13:14 GMT, Chris Hegarty wrote: >> Update Class::isRecord to only return true for classes that are final. >> >> The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. >> >> Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: >> >> 1. It is a compile-time error if a record declaration has the modifier abstract. >> 2. A record declaration is implicitly final. >> 3. The direct superclass type of a record class is Record. >> >> Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Mandy's review comments `{@link ... final}` should be `@linkplain`. Otherwise, looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1543 From jfranck at openjdk.java.net Tue Dec 1 21:18:11 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 1 Dec 2020 21:18:11 GMT Subject: RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2] In-Reply-To: References: Message-ID: <4SY2QMuEjP-QulYVeNLLpri3POeOZwZwTO1qLpDnIxg=.f1674bd6-c789-4efa-b223-5aefe5df9588@github.com> > The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. Joel Borggr?n-Franck has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into jdk8256693 - Add javadoc note explaining empty type arguments array Check type argument arrays from ParameterizedType and AnnotatedParameterizedType has same length testing generation of the empty case. - 8256693: getAnnotatedReceiverType parameterizes types too eagerly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1414/files - new: https://git.openjdk.java.net/jdk/pull/1414/files/f82b30a7..2f138ce8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1414&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1414&range=00-01 Stats: 27103 lines in 668 files changed: 15342 ins; 4027 del; 7734 mod Patch: https://git.openjdk.java.net/jdk/pull/1414.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1414/head:pull/1414 PR: https://git.openjdk.java.net/jdk/pull/1414 From ccheung at openjdk.java.net Tue Dec 1 21:58:17 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 21:58:17 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: <5kvJTqBrgXuMhMfr0h28756D9_yiyYLJPRYyybhDTcg=.0f1cc550-e763-4b11-bb6a-cae1d70e4f4d@github.com> On Tue, 1 Dec 2020 20:50:11 GMT, Claes Redestad wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> added a test > > Looks good to me! @mlchung, @iklam, @cl4es Thanks for the review. I've added a test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Tue Dec 1 21:58:16 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 21:58:16 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: added a test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/812777b3..880407c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=00-01 Stats: 88 lines in 1 file changed: 88 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From rriggs at openjdk.java.net Tue Dec 1 22:08:55 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Dec 2020 22:08:55 GMT Subject: RFR: 8207329: Add NIL Constant to UUID In-Reply-To: References: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com> Message-ID: On Fri, 27 Nov 2020 18:42:49 GMT, Richard Fussenegger wrote: >> The bug report does not make a strong case for adding a NIL constant to the UUID API. >> It would add (a small amount) to both footprint and startup time with very limited benefit. >> Any application needing a placeholder can do so itself and all existing applications take care of their own needs. > > For me it's mostly useful in tests but we cannot ship test only code. We could fix the issues you mention through lazy initialization, or we simply close the PR and ticket and state that the construction via `new UUID(0, 0)` is already simple enough. There being no other comments supporting this enhancement, I propose to close this PR **without** integrating. I'll take care of closing the bug as will-not-fix. It can be reopened if new information becomes available. For any API addition, its useful to do an email query on core-libs-dev at openjdk.net to see if there is support for API enhancements. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/1460 From rriggs at openjdk.java.net Tue Dec 1 22:20:16 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Dec 2020 22:20:16 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v13] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Review comment updates: - misc javadoc markup fixes. - added checking of byte array sizes to generate useful exceptions if the arrays would be too large. - Small implementation cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/a1ce9d7c..bbcb2135 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=11-12 Stats: 63 lines in 4 files changed: 35 ins; 1 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From rriggs at openjdk.java.net Tue Dec 1 22:20:17 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Dec 2020 22:20:17 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v12] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 11:25:15 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F. >> Added a test to verify isHexDigit and fromHexDigit for the entire range of chars > > src/java.base/share/classes/java/util/HexFormat.java line 887: > >> 885: * The characters in the range from {@code index} to {@code index + 1}, >> 886: * inclusive, must be valid hex digits according to {@link #fromHexDigit(int)}. >> 887: * The delimiter, prefix and suffix are not used. > > In this method - and all similar methods that follow - then is `isUpperCase()` taken into account? If not maybe it should be made explicit - just as for delimiter, prefix, and suffix? > Alternatively, remove this line and make the method static. Then it would be clear that upperCase, delimiter, prefix, and suffix are not used. This is a private method, documented more than is usual. The fromHexDigit() method it calls is an instance method to be consistent in the API with the other methods and still have the context of the HexFormat, allowing for possible futures. (For example, a strict vs lenient setting with respect to uppercase). The caller is free to use the static method in Character.digit(ch, 16) if that is a better fit.. ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From vlivanov at openjdk.java.net Tue Dec 1 22:20:58 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 1 Dec 2020 22:20:58 GMT Subject: RFR: 8257537: [vector] Cleanup redundant bitwise cases on floating point vectors In-Reply-To: References: Message-ID: <4VSY6kLnC5g9U7eUhxDqZ3mpan2ncJjvRIBJt2ltNrA=.4d7c1966-bb77-4e0f-96b1-be79e1396794@github.com> On Tue, 1 Dec 2020 20:36:48 GMT, Paul Sandoz wrote: > Float/DoubleVector implementations contain redundant cases for bitwise operations. Such bitwise operations will fail on such FP vectors before the case is reached. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1544 From mchung at openjdk.java.net Tue Dec 1 22:22:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 22:22:58 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:58:16 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > added a test test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36: > 34: * @requires vm.cds > 35: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 36: * @compile ../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java I think it's better to make a copy of this test along side with this test. test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 77: > 75: .shouldHaveExitValue(0); > 76: > 77: // run with archive without the -Djdk.internal.lambda.disableEagerInitialization=true property Minor suggestion: make this test case in a separate `testWithEagerInitializationEnabled` method. `testImpl` can be renamed to `testWithEagerInitializationDisabled`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Tue Dec 1 22:37:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 22:37:56 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 22:16:58 GMT, Mandy Chung wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> added a test > > test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36: > >> 34: * @requires vm.cds >> 35: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 36: * @compile ../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java > > I think it's better to make a copy of this test along side with this test. I can make a copy and put it under the `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still need the `@compile` and would be something like `@compile test-classes/LambdaEagerInitTest.java`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From iklam at openjdk.java.net Tue Dec 1 22:50:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 22:50:00 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: <5SrwCM5wt1oa2h1Rg8lpC0YASOX70akzMQ8XYNpAjCo=.3f8219d7-ea70-4c28-b004-3c8a6e9cfed5@github.com> On Tue, 1 Dec 2020 22:34:58 GMT, Calvin Cheung wrote: >> test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36: >> >>> 34: * @requires vm.cds >>> 35: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >>> 36: * @compile ../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java >> >> I think it's better to make a copy of this test along side with this test. > > I can make a copy and put it under the `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still need the `@compile` and would be something like `@compile test-classes/LambdaEagerInitTest.java`. The `@compile` can be avoiding by putting LambdaEagerInitTest into the `@library` and referencing it as private static final String mainClass = LambdaEagerInitTest.class.getName(); ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From rriggs at openjdk.java.net Tue Dec 1 22:50:19 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Dec 2020 22:50:19 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v14] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Increased memory to 4G for the test and add diagnostic info for OOME ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/bbcb2135..892d08e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=12-13 Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From redestad at openjdk.java.net Tue Dec 1 22:52:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 1 Dec 2020 22:52:55 GMT Subject: Integrated: 8257511: JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:49:01 GMT, Claes Redestad wrote: > This patch fixes a place where we failed to adjust properly for getBytes taking a length rather than end offset. (Something the public API in AbstractStringBuilder is apparently inconsistent about..) > > Although this was caught by JCK testing, this patch adds a few trivial sanity tests to get at least some sanity checking into tier1 This pull request has now been integrated. Changeset: 00e79db8 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/00e79db8 Stats: 25 lines in 2 files changed: 16 ins; 0 del; 9 mod 8257511: JDK-8254082 brings regression to AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) Reviewed-by: alanb, rriggs, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/1541 From ccheung at openjdk.java.net Tue Dec 1 23:16:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 23:16:13 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v3] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: 1. Make a copy of LambdaEagerInitTest.java to the test-classes dir 2. Modifications to LambdaEagerInit.java per review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/880407c1..edd4a094 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=01-02 Stats: 24 lines in 2 files changed: 11 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From mchung at openjdk.java.net Tue Dec 1 23:21:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 23:21:56 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda wrote: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio >From David's comment: > These subtleties are what I was also getting at in the CSR discussion. If Foo lists Bar as a permitted subtype, but Bar does not extend Foo, is that an error? Should Bar not be returned by getPermittedSubclasses? The answer depends on exactly how you specify getPermittedSubclasses() and whether that aligns with reading the classfile attribute, or actually checking the runtime relationships. As I read the current spec of `Class::getPermittedSubclasses`, it intends to return the direct subclasses or subinterfaces permitted to extend or implement this class or interface if it's sealed. If not, it should be clarified that it is the class file view. `NestMembers` and `PermittedSubclasses` attributes are critical to correct interpretation of the class file by JVM. Prior to these two attributes, the attributes inspected by core reflection APIs are all non-critical. API like `Class::getDeclaringClass` reads `InnerClasses` attribute if present in order to determine its declaring class but the current spec does not specify the behavior on error cases (which I consider a spec bug - see JDK-8250226.) IMO it is reasonable for `getPermittedSubclasses` (and `getNestMembers` and `getNestHost`) to return the runtime view as it returns `Class` objects since these attributes are critical to correct interpretation of the class file. It would be confusing if it returns `Foo` that is not a permitted subtype at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Tue Dec 1 23:21:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 23:21:58 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On Tue, 1 Dec 2020 16:49:03 GMT, Jan Lahoda wrote: >> So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right? >> >> The specification of `Class::getPermittedSubclasses` says: >> >>> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. >> >> I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime. > > I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module). > > Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included. > > So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class. > > My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). > > [1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5 @lahodaj It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From ccheung at openjdk.java.net Tue Dec 1 23:25:57 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 23:25:57 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: <5SrwCM5wt1oa2h1Rg8lpC0YASOX70akzMQ8XYNpAjCo=.3f8219d7-ea70-4c28-b004-3c8a6e9cfed5@github.com> References: <5SrwCM5wt1oa2h1Rg8lpC0YASOX70akzMQ8XYNpAjCo=.3f8219d7-ea70-4c28-b004-3c8a6e9cfed5@github.com> Message-ID: On Tue, 1 Dec 2020 22:47:18 GMT, Ioi Lam wrote: >> I can make a copy and put it under the `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still need the `@compile` and would be something like `@compile test-classes/LambdaEagerInitTest.java`. > > The `@compile` can be avoiding by putting LambdaEagerInitTest into the `@library` and referencing it as > > private static final String mainClass = LambdaEagerInitTest.class.getName(); Yes, `@library test-classes` works. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Tue Dec 1 23:26:00 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 23:26:00 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: <9QgNHvpiNC38l90LZoQC2kZpbzXv1YB7v5lmx_skBLk=.bfe1e254-9ffa-47e8-a3b7-381e1674357b@github.com> On Tue, 1 Dec 2020 22:19:55 GMT, Mandy Chung wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> added a test > > test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 77: > >> 75: .shouldHaveExitValue(0); >> 76: >> 77: // run with archive without the -Djdk.internal.lambda.disableEagerInitialization=true property > > Minor suggestion: make this test case in a separate `testWithEagerInitializationEnabled` method. `testImpl` can be renamed to `testWithEagerInitializationDisabled`. I also factored out the archive creation into the `createArchiveWithEagerInitializationEnabled` method. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From mchung at openjdk.java.net Tue Dec 1 23:29:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 23:29:58 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:16:13 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > 1. Make a copy of LambdaEagerInitTest.java to the test-classes dir > 2. Modifications to LambdaEagerInit.java per review comments test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaEagerInitTest.java line 25: > 23: > 24: /** > 25: * @test This is part of LambdaEagerInit test. This does not need to be `@test` and so the entire comment block can be removed. If you want to verify, you could add a test case in LambdaEagerInit.java to run this main class without the CDS archive. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Wed Dec 2 01:12:17 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 2 Dec 2020 01:12:17 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v4] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: 1. Update comment block in LambdaEagerInitTest.java 2. Add more test cases using the default CDS archive in LambdaEagerInit.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/edd4a094..fc10e77f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=02-03 Stats: 46 lines in 2 files changed: 32 ins; 5 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From psandoz at openjdk.java.net Wed Dec 2 02:04:56 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Dec 2020 02:04:56 GMT Subject: Integrated: 8257537: [vector] Cleanup redundant bitwise cases on floating point vectors In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:36:48 GMT, Paul Sandoz wrote: > Float/DoubleVector implementations contain redundant cases for bitwise operations. Such bitwise operations will fail on such FP vectors before the case is reached. This pull request has now been integrated. Changeset: cfd070ec Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/cfd070ec Stats: 28 lines in 3 files changed: 4 ins; 24 del; 0 mod 8257537: [vector] Cleanup redundant bitwise cases on floating point vectors Reviewed-by: vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/1544 From iklam at openjdk.java.net Wed Dec 2 05:36:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 05:36:01 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 01:12:17 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > 1. Update comment block in LambdaEagerInitTest.java > 2. Add more test cases using the default CDS archive in LambdaEagerInit.java Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From github.com+1059453+fleshgrinder at openjdk.java.net Wed Dec 2 07:27:59 2020 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Wed, 2 Dec 2020 07:27:59 GMT Subject: Withdrawn: 8207329: Add NIL Constant to UUID In-Reply-To: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com> References: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com> Message-ID: On Thu, 26 Nov 2020 15:54:46 GMT, Richard Fussenegger wrote: > Adds a constant for the special NIL UUID where all bits are zero to `java.util.UUID`. The [8207329](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8207329) mentions the usage of it to avoid `null`, it for sure is also very handy in testing where a UUID is required and we do not care about its actual value. Using a random UUID stresses the PRNG for no good reason. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1460 From chegar at openjdk.java.net Wed Dec 2 09:38:15 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Dec 2020 09:38:15 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v3] In-Reply-To: References: Message-ID: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1543/files - new: https://git.openjdk.java.net/jdk/pull/1543/files/d626eeed..1aa59363 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1543/head:pull/1543 PR: https://git.openjdk.java.net/jdk/pull/1543 From chegar at openjdk.java.net Wed Dec 2 10:00:21 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Dec 2020 10:00:21 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v4] In-Reply-To: References: Message-ID: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: fix issue in ByteCodeLoader ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1543/files - new: https://git.openjdk.java.net/jdk/pull/1543/files/1aa59363..4eb26488 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=02-03 Stats: 16 lines in 1 file changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1543/head:pull/1543 PR: https://git.openjdk.java.net/jdk/pull/1543 From chegar at openjdk.java.net Wed Dec 2 10:45:55 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Dec 2020 10:45:55 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:04:34 GMT, Mandy Chung wrote: > `{@link ... final}` should be `@linkplain`. Otherwise, looks good. Oops! Yes, changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1543 From cay.horstmann at gmail.com Wed Dec 2 10:53:44 2020 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Wed, 2 Dec 2020 11:53:44 +0100 Subject: MatchResult support for named groups In-Reply-To: <14517.1606845585151306433@groups.io> References: <14517.1606845585151306433@groups.io> Message-ID: Hello, I'd like to raise awareness for https://bugs.openjdk.java.net/browse/JDK-8180352 https://bugs.openjdk.java.net/browse/JDK-8072984 https://bugs.openjdk.java.net/browse/JDK-8065554 These all ask for MatchResult.group(String name). What they don't mention is that this is more urgent in light of the methods Stream Matcher.results() // https://bugs.openjdk.java.net/browse/JDK-8071479 Stream Scanner.findAll(Pattern pattern) // https://bugs.openjdk.java.net/browse/JDK-8072722 In particular, Matcher.results() seems a cleaner way of collecting match results than calling while (matcher.find()). But then MatchResult needs to support the same queries that Matcher provides. I believe the only missing one is group(String name). Cheers, Cay NB. There are related requests that ask for finding group names in patterns, or for correlating group names and numbers. I have formed no opinion on their merits. -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From dfuchs at openjdk.java.net Wed Dec 2 11:17:01 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Dec 2020 11:17:01 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v14] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 22:50:19 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Increased memory to 4G for the test and add diagnostic info for OOME Changes requested by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From dfuchs at openjdk.java.net Wed Dec 2 11:17:02 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Dec 2020 11:17:02 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v12] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 16:08:05 GMT, Roger Riggs wrote: > This is a private method, documented more than is usual. Sorry - my comment was misplaced. I was mostly concerned with the *public* methods that follow. (` public int fromHexDigits(CharSequence string)` and friends) They all say that `* The delimiter, prefix and suffix are not used.` but they do not say anything about upperCase/lowerCase. Since this is normative specification doesn't it need to be fixed? ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From vlivanov at openjdk.java.net Wed Dec 2 11:42:16 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 11:42:16 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> Message-ID: <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> On Tue, 1 Dec 2020 15:55:36 GMT, Peter Levart wrote: >> It seems that I was right. See `ciField.cpp`: >> >> static bool trust_final_non_static_fields(ciInstanceKlass* holder) { >> if (holder == NULL) >> return false; >> if (holder->name() == ciSymbol::java_lang_System()) >> // Never trust strangely unstable finals: System.out, etc. >> return false; >> // Even if general trusting is disabled, trust system-built closures in these packages. >> if (holder->is_in_package("java/lang/invoke") || holder->is_in_package("sun/invoke") || >> holder->is_in_package("jdk/internal/foreign") || holder->is_in_package("jdk/incubator/foreign") || >> holder->is_in_package("jdk/internal/vm/vector") || holder->is_in_package("jdk/incubator/vector") || >> holder->is_in_package("java/lang")) >> return true; > > I mean, is it possible that some threads that concurrently use the old uncustomized form while one thread is customizing it, trigger JIT compilation and because `form` field is trusted final, the JITed code will be using the uncustomized form for ever. Even after the customization thread plants the new form... This was possible before, but maybe the probability is greater after this change. Thanks for the review, Peter. The contract of `updateForm` clearly states that there are no guarantees provided about visibility: /** * Replace the old lambda form of this method handle with a new one. * The new one must be functionally equivalent to the old one. * Threads may continue running the old form indefinitely, * but it is likely that the new one will be preferred for new executions. * Use with discretion. */ It is used solely for performance reasons: install a faster LambdaForm variant and hope more users catch it. Regarding `finally`, the intention of `updateInProgress` is to signal that there's a thread already preparing an updated form. Once it is done, the flag should be set back to `false` to allow more updates in the future. Indeed, there's a small window when another thread may succeed in acquiring the flag and performing the very same update, but (1) it's benign (it's still a performance optimization, so the more threads avoid redundant update the better); and (2) there are fast-path checks in place (like `customized == mh` in `MH.customize()` or 'oldForm != newForm`) to detect such cases and don't waste resources. Does it resolve your concerns? ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From vlivanov at openjdk.java.net Wed Dec 2 11:42:16 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 11:42:16 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: > Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. > > Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked. > > Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. > > Testing: > - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049) > - tier1-4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Minor cleanups - Merge branch 'master' into 8257189.mh.customization.concurrent - Improve concurrent LF customization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1472/files - new: https://git.openjdk.java.net/jdk/pull/1472/files/1780f57f..9cf759ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1472&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1472&range=00-01 Stats: 23494 lines in 558 files changed: 13055 ins; 3034 del; 7405 mod Patch: https://git.openjdk.java.net/jdk/pull/1472.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1472/head:pull/1472 PR: https://git.openjdk.java.net/jdk/pull/1472 From alanb at openjdk.java.net Wed Dec 2 12:10:54 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Dec 2020 12:10:54 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On Tue, 1 Dec 2020 23:19:41 GMT, Mandy Chung wrote: >> I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module). >> >> Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included. >> >> So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class. >> >> My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). >> >> [1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5 > > @lahodaj It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up. Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From jlahoda at openjdk.java.net Wed Dec 2 12:13:54 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 2 Dec 2020 12:13:54 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On Wed, 2 Dec 2020 12:08:09 GMT, Alan Bateman wrote: >> @lahodaj It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up. > > Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in. FWIW: I plan to change the method to not return such Class objects. It just will do the verification in Java, while for getNestMembers it is done in native. The follow up is for investigate the possibility of making the internal behavior consistent with how getNestMembers work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From chegar at openjdk.java.net Wed Dec 2 12:39:59 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Dec 2020 12:39:59 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2] In-Reply-To: References: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com> Message-ID: On Wed, 2 Dec 2020 12:11:16 GMT, Jan Lahoda wrote: >> Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in. > > FWIW: I plan to change the method to not return such Class objects. It just will do the verification in Java, while for getNestMembers it is done in native. The follow up is for investigate the possibility of making the internal behavior consistent with how getNestMembers work. For the record: similar/related questions/comments have been made on a-s-e [1][2]. The questions/comments were made in order to clarify the JVMS specification, so as to better inform what responsibilities are part Core Reflection versus what are part of the VM. [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-October/002626.html [2] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002660.html ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From rriggs at openjdk.java.net Wed Dec 2 14:21:16 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Dec 2020 14:21:16 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v15] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarify that the fromHexDigits does not use the uppercase parameter. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/892d08e9..a1377407 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=13-14 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From rriggs at openjdk.java.net Wed Dec 2 14:25:04 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Dec 2020 14:25:04 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v14] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:14:18 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Increased memory to 4G for the test and add diagnostic info for OOME > > Changes requested by dfuchs (Reviewer). @dfuch I'll add a clarification. The fromHexDigits methods explicitly parse using the fromHexDigit method that is specified to include both upper and lower case. > I was mostly concerned with the public methods that follow. ( public int fromHexDigits(CharSequence string) and friends) They all say that * The delimiter, prefix and suffix are not used. but they do not say anything about upperCase/lowerCase. Since this is normative specification doesn't it need to be fixed? ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From hseigel at openjdk.java.net Wed Dec 2 14:30:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 14:30:57 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:16:45 GMT, Mandy Chung wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > From David's comment: > >> These subtleties are what I was also getting at in the CSR discussion. If Foo lists Bar as a permitted subtype, but Bar does not extend Foo, is that an error? Should Bar not be returned by getPermittedSubclasses? The answer depends on exactly how you specify getPermittedSubclasses() and whether that aligns with reading the classfile attribute, or actually checking the runtime relationships. > > As I read the current spec of `Class::getPermittedSubclasses`, it intends to return the direct subclasses or subinterfaces permitted to extend or implement this class or interface if it's sealed. If not, it should be clarified that it is the class file view. > > `NestMembers` and `PermittedSubclasses` attributes are critical to correct interpretation of the class file by JVM. Prior to these two attributes, the attributes inspected by core reflection APIs are all non-critical. API like `Class::getDeclaringClass` reads `InnerClasses` attribute if present in order to determine its declaring class but the current spec does not specify the behavior on error cases (which I consider a spec bug - see JDK-8250226.) > > IMO it is reasonable for `getPermittedSubclasses` (and `getNestMembers` and `getNestHost`) to return the runtime view as it returns `Class` objects since these attributes are critical to correct interpretation of the class file. It would be confusing if it returns `Foo` that is not a permitted subtype at runtime. Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented). Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses(). Does this seem like a reasonable way to handle this corner case? ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From plevart at openjdk.java.net Wed Dec 2 14:33:55 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Dec 2020 14:33:55 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> Message-ID: On Wed, 2 Dec 2020 11:37:07 GMT, Vladimir Ivanov wrote: >> I mean, is it possible that some threads that concurrently use the old uncustomized form while one thread is customizing it, trigger JIT compilation and because `form` field is trusted final, the JITed code will be using the uncustomized form for ever. Even after the customization thread plants the new form... This was possible before, but maybe the probability is greater after this change. > > Thanks for the review, Peter. > The contract of `updateForm` clearly states that there are no guarantees provided about visibility: > /** > * Replace the old lambda form of this method handle with a new one. > * The new one must be functionally equivalent to the old one. > * Threads may continue running the old form indefinitely, > * but it is likely that the new one will be preferred for new executions. > * Use with discretion. > */ > It is used solely for performance reasons: install a faster LambdaForm variant and hope more users catch it. > > Regarding `finally`, the intention of `updateInProgress` is to signal that there's a thread already preparing an updated form. Once it is done, the flag should be set back to `false` to allow more updates in the future. Indeed, there's a small window when another thread may succeed in acquiring the flag and performing the very same update, but (1) it's benign (it's still a performance optimization, so the more threads avoid redundant update the better); and (2) there are fast-path checks in place (like `customized == mh` in `MH.customize()` or 'oldForm != newForm`) to detect such cases and don't waste resources. > > Does it resolve your concerns? I see. So a MH.form may be updated several times in succession. I was just concerned that optimization in one part (less resources consumed updating the form) would increase the probability of JIT-ed code using the old form indefinitely - therefore causing regression in top performance. If you think that in spite of MH.form being trusted final field, such probability stays low, then my concern is unfounded. Before the patch, each thread that saw opportunity to update form, started updating form immediately, therefore preventing JIT to kick-in before at least one of updated forms was installed on MH.form. Now, while one thread is updating the form, other threads freely execute the old form, so there is more opportunity for JIT to kick-in during that time and compile a constant-folded old form. I wonder if it is possible to construct a concurrent test to provoke that. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From plevart at openjdk.java.net Wed Dec 2 14:38:57 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Dec 2020 14:38:57 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> Message-ID: On Wed, 2 Dec 2020 14:30:57 GMT, Peter Levart wrote: >> Thanks for the review, Peter. >> The contract of `updateForm` clearly states that there are no guarantees provided about visibility: >> /** >> * Replace the old lambda form of this method handle with a new one. >> * The new one must be functionally equivalent to the old one. >> * Threads may continue running the old form indefinitely, >> * but it is likely that the new one will be preferred for new executions. >> * Use with discretion. >> */ >> It is used solely for performance reasons: install a faster LambdaForm variant and hope more users catch it. >> >> Regarding `finally`, the intention of `updateInProgress` is to signal that there's a thread already preparing an updated form. Once it is done, the flag should be set back to `false` to allow more updates in the future. Indeed, there's a small window when another thread may succeed in acquiring the flag and performing the very same update, but (1) it's benign (it's still a performance optimization, so the more threads avoid redundant update the better); and (2) there are fast-path checks in place (like `customized == mh` in `MH.customize()` or 'oldForm != newForm`) to detect such cases and don't waste resources. >> >> Does it resolve your concerns? > > I see. So a MH.form may be updated several times in succession. > I was just concerned that optimization in one part (less resources consumed updating the form) would increase the probability of JIT-ed code using the old form indefinitely - therefore causing regression in top performance. If you think that in spite of MH.form being trusted final field, such probability stays low, then my concern is unfounded. > Before the patch, each thread that saw opportunity to update form, started updating form immediately, therefore preventing JIT to kick-in before at least one of updated forms was installed on MH.form. Now, while one thread is updating the form, other threads freely execute the old form, so there is more opportunity for JIT to kick-in during that time and compile a constant-folded old form. > I wonder if it is possible to construct a concurrent test to provoke that. WDYT? Would it make a difference if MH.form was not final and each read access to it was done via appropriate Unsafe.getReferenceXXX()? ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From jlahoda at openjdk.java.net Wed Dec 2 14:40:15 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 2 Dec 2020 14:40:15 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v3] In-Reply-To: References: Message-ID: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1483/files - new: https://git.openjdk.java.net/jdk/pull/1483/files/4d484179..ff1abf06 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=01-02 Stats: 250 lines in 8 files changed: 217 ins; 14 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483 PR: https://git.openjdk.java.net/jdk/pull/1483 From rriggs at openjdk.java.net Wed Dec 2 14:55:18 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Dec 2020 14:55:18 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v16] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarify that the fromHexDigit method does not use the prefix, suffix, delimiter, or uppercase parameter. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/a1377407..848c7a61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=14-15 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From jboes at openjdk.java.net Wed Dec 2 14:57:01 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 2 Dec 2020 14:57:01 GMT Subject: RFR: 8256679: Update serialization javadoc once JOSS changes for records are complete Message-ID: Now that the changes for record serialization are integrated into the Java Object Serialization Specification, this change updates the serialization javadocs in ObjectInputStream, ObjectOutputStream, Serializable and java.lang.Record. Additionally, the suppression of preview related warnings is removed in ObjectStreamClass. ------------- Commit messages: - fix link and new line - replace 'type' with 'class' - change javadoc wording and links - remove SuppressWarnings and change javadoc Changes: https://git.openjdk.java.net/jdk/pull/1564/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1564&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256679 Stats: 58 lines in 5 files changed: 8 ins; 34 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1564/head:pull/1564 PR: https://git.openjdk.java.net/jdk/pull/1564 From vlivanov at openjdk.java.net Wed Dec 2 15:27:57 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 15:27:57 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> Message-ID: On Wed, 2 Dec 2020 14:36:16 GMT, Peter Levart wrote: > Would it make a difference if MH.form was not final and each read access to it was done via appropriate Unsafe.getReferenceXXX()? It would break inlining through MH calls. JITs trust `MH.form` and aggressively inline through it. >I was just concerned that optimization in one part (less resources consumed updating the form) would increase the probability of JIT-ed code using the old form indefinitely - therefore causing regression in top performance. That's expected and happens in practice. It was a deliberate choice to avoid invalidating existing code and triggering recompilations while sacrificing some performance. But if we focus on MH customization, there's no inlining happening (or possible): customization is performed on a non-constant (in JIT sense) MH instance which is about to be invoked through `MH.invoke()/invokeExact()`. So, subsequent calls through invoker on the same (non-constant) MH instance should see updated `MH.form` value (customized LambdaForm): https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/Invokers.java#L598 @ForceInline /*non-public*/ static void checkCustomized(MethodHandle mh) { if (MethodHandleImpl.isCompileConstant(mh)) { return; // no need to customize a MH when the instance is known to JIT } if (mh.form.customized == null) { // fast approximate check that the underlying form is already customized maybeCustomize(mh); // marked w/ @DontInline } } ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From plevart at openjdk.java.net Wed Dec 2 15:32:55 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Dec 2020 15:32:55 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> Message-ID: On Wed, 2 Dec 2020 15:24:47 GMT, Vladimir Ivanov wrote: >> Would it make a difference if MH.form was not final and each read access to it was done via appropriate Unsafe.getReferenceXXX()? > >> Would it make a difference if MH.form was not final and each read access to it was done via appropriate Unsafe.getReferenceXXX()? > > It would break inlining through MH calls. JITs trust `MH.form` and aggressively inline through it. > >>I was just concerned that optimization in one part (less resources consumed updating the form) would increase the probability of JIT-ed code using the old form indefinitely - therefore causing regression in top performance. > > That's expected and happens in practice. It was a deliberate choice to avoid invalidating existing code and triggering recompilations while sacrificing some performance. > > But if we focus on MH customization, there's no inlining happening (or possible): customization is performed on a non-constant (in JIT sense) MH instance which is about to be invoked through `MH.invoke()/invokeExact()`. So, subsequent calls through invoker on the same (non-constant) MH instance should see updated `MH.form` value (customized LambdaForm): > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/Invokers.java#L598 > @ForceInline > /*non-public*/ > static void checkCustomized(MethodHandle mh) { > if (MethodHandleImpl.isCompileConstant(mh)) { > return; // no need to customize a MH when the instance is known to JIT > } > if (mh.form.customized == null) { // fast approximate check that the underlying form is already customized > maybeCustomize(mh); // marked w/ @DontInline > } > } Ah, I see. Customization only happens for non-constant MHs. Everything is fine then. Sorry for confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From chegar at openjdk.java.net Wed Dec 2 16:13:56 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Dec 2020 16:13:56 GMT Subject: RFR: 8256679: Update serialization javadoc once JOSS changes for records are complete In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 14:51:23 GMT, Julia Boes wrote: > Now that the changes for record serialization are integrated into the Java Object Serialization Specification, this change updates the serialization javadocs in ObjectInputStream, ObjectOutputStream, Serializable and java.lang.Record. Additionally, the suppression of preview related warnings is removed in ObjectOutputStream and ObjectStreamClass. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8257592 Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1564 From dfuchs at openjdk.java.net Wed Dec 2 16:17:02 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Dec 2020 16:17:02 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v16] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 14:55:18 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that the fromHexDigit method does not use the prefix, suffix, delimiter, or uppercase parameter. src/java.base/share/classes/java/util/HexFormat.java line 675: > 673: * The hexadecimal characters are appended in one or more calls to the > 674: * {@link Appendable} methods. > 675: * For parity with the method `public String toHexDigits(byte value)` above I would suggest to add the text * The delimiter, prefix and suffix are not used. here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From rriggs at openjdk.java.net Wed Dec 2 16:19:58 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Dec 2020 16:19:58 GMT Subject: RFR: 8256679: Update serialization javadoc once JOSS changes for records are complete In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 14:51:23 GMT, Julia Boes wrote: > Now that the changes for record serialization are integrated into the Java Object Serialization Specification, this change updates the serialization javadocs in ObjectInputStream, ObjectOutputStream, Serializable and java.lang.Record. Additionally, the suppression of preview related warnings is removed in ObjectOutputStream and ObjectStreamClass. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8257592 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1564 From rriggs at openjdk.java.net Wed Dec 2 16:33:15 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Dec 2020 16:33:15 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add class level clarification of use of uppercase for primitive conversions Switched order of declaration of a couple of method to make the javadoc sequence easier to read ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/848c7a61..0a8088b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=15-16 Stats: 45 lines in 1 file changed: 23 ins; 20 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From mchung at openjdk.java.net Wed Dec 2 16:58:59 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Dec 2020 16:58:59 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 01:12:17 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > 1. Update comment block in LambdaEagerInitTest.java > 2. Add more test cases using the default CDS archive in LambdaEagerInit.java Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From vlivanov at openjdk.java.net Wed Dec 2 17:27:57 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 17:27:57 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <9kCIDK9wU1zqxqMln8q6PXQ6AU51hLkKOp9LEb7gPQ4=.645e2e80-5257-4c2b-8798-d753f08de3de@github.com> <9LjatTC1OtQcymCUtqnNQbSmEZ9qaNt6nt2JGBtAyF0=.e2bafdcb-8590-46ae-80dc-3f16c3bb3759@github.com> Message-ID: On Wed, 2 Dec 2020 15:30:07 GMT, Peter Levart wrote: >>> Would it make a difference if MH.form was not final and each read access to it was done via appropriate Unsafe.getReferenceXXX()? >> >> It would break inlining through MH calls. JITs trust `MH.form` and aggressively inline through it. >> >>>I was just concerned that optimization in one part (less resources consumed updating the form) would increase the probability of JIT-ed code using the old form indefinitely - therefore causing regression in top performance. >> >> That's expected and happens in practice. It was a deliberate choice to avoid invalidating existing code and triggering recompilations while sacrificing some performance. >> >> But if we focus on MH customization, there's no inlining happening (or possible): customization is performed on a non-constant (in JIT sense) MH instance which is about to be invoked through `MH.invoke()/invokeExact()`. So, subsequent calls through invoker on the same (non-constant) MH instance should see updated `MH.form` value (customized LambdaForm): >> >> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/Invokers.java#L598 >> @ForceInline >> /*non-public*/ >> static void checkCustomized(MethodHandle mh) { >> if (MethodHandleImpl.isCompileConstant(mh)) { >> return; // no need to customize a MH when the instance is known to JIT >> } >> if (mh.form.customized == null) { // fast approximate check that the underlying form is already customized >> maybeCustomize(mh); // marked w/ @DontInline >> } >> } > > Ah, I see. Customization only happens for non-constant MHs. Everything is fine then. Sorry for confusion. Thanks a lot for such a thorough review, Peter! ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From vlivanov at openjdk.java.net Wed Dec 2 17:30:56 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 17:30:56 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: <08fJzjQ3tTBWMI30I8cAZJsOaFR5c_fDOKVSGPv1jWA=.6c0ba4ae-4e82-4650-bb74-c563abf74238@github.com> On Mon, 30 Nov 2020 19:32:54 GMT, Paul Sandoz wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Minor cleanups >> - Merge branch 'master' into 8257189.mh.customization.concurrent >> - Improve concurrent LF customization > > Marked as reviewed by psandoz (Reviewer). Thanks for the reviews, Claes, Paul, and Peter. ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From vlivanov at openjdk.java.net Wed Dec 2 17:30:56 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 17:30:56 GMT Subject: RFR: 8257189: Handle concurrent updates of MH.form better [v2] In-Reply-To: <08fJzjQ3tTBWMI30I8cAZJsOaFR5c_fDOKVSGPv1jWA=.6c0ba4ae-4e82-4650-bb74-c563abf74238@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> <08fJzjQ3tTBWMI30I8cAZJsOaFR5c_fDOKVSGPv1jWA=.6c0ba4ae-4e82-4650-bb74-c563abf74238@github.com> Message-ID: On Wed, 2 Dec 2020 17:28:15 GMT, Vladimir Ivanov wrote: >> Marked as reviewed by psandoz (Reviewer). > > Thanks for the reviews, Claes, Paul, and Peter. \integrate ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From vlivanov at openjdk.java.net Wed Dec 2 17:38:56 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 17:38:56 GMT Subject: Integrated: 8257189: Handle concurrent updates of MH.form better In-Reply-To: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com> Message-ID: On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote: > Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. > > Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked. > > Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. > > Testing: > - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049) > - tier1-4 This pull request has now been integrated. Changeset: 692b273e Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/692b273e Stats: 89 lines in 5 files changed: 36 ins; 20 del; 33 mod 8257189: Handle concurrent updates of MH.form better Reviewed-by: redestad, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/1472 From vlivanov at openjdk.java.net Wed Dec 2 17:39:55 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 17:39:55 GMT Subject: RFR: 8257164: Share LambdaForms for VH linkers/invokers. In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 19:38:56 GMT, Paul Sandoz wrote: >> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers. >> It reduces the number of LambdaForms needed at runtime. >> >> Testing: tier1-4 > > Marked as reviewed by psandoz (Reviewer). Thanks for the reviews, Claes, Vladimir, and Paul. ------------- PR: https://git.openjdk.java.net/jdk/pull/1455 From jlahoda at openjdk.java.net Wed Dec 2 17:42:58 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 2 Dec 2020 17:42:58 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 14:28:00 GMT, Harold Seigel wrote: > Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented). > > Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses(). > > Does this seem like a reasonable way to handle this corner case? Uh, I just realized it may be necessary to implement `Class.isSealed()` differently. Consider: sealed class Sealed permits Unknown {} Where `Unknown` does not exist at runtime. So getPermittedSubclasses0() returns an empty array(?). But isSealed should return `true`, right? (Possibly, we could leave this from the first integration, but seems like something that should be done. Note that in the previous/JDK 15 implementation, isSealed() would return true in this case.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From akozlov at openjdk.java.net Wed Dec 2 17:46:04 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Dec 2020 17:46:04 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version Message-ID: Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. ------------- Commit messages: - Do not use objc_msgSend_stret to get macOS version Changes: https://git.openjdk.java.net/jdk/pull/1569/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1569&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257620 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1569.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1569/head:pull/1569 PR: https://git.openjdk.java.net/jdk/pull/1569 From chegar at openjdk.java.net Wed Dec 2 17:48:57 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Dec 2020 17:48:57 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: <3TxnaMFicwJfi4HebVySfGtUpBjMR2zEG22gyWDvc1g=.55e08627-ba5c-4e76-9025-ef8c5e6331f3@github.com> On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda wrote: > ... > Uh, I just realized it may be necessary to implement `Class.isSealed()` differently. Consider: > > ``` > sealed class Sealed permits Unknown {} > ``` > > Where `Unknown` does not exist at runtime. So getPermittedSubclasses0() returns an empty array(?). But isSealed should return `true`, right? (Possibly, we could leave this from the first integration, but seems like something that should be done. Note that in the previous/JDK 15 implementation, isSealed() would return true in this case.) @lahodaj I raised this issue here: https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-October/002626.html Relevant comment inline: > The recent change (proposed on this list) to Class::getPermittedSubclasses, means that it will no longer be possible to reflectively return permitted subclasses that are not loaded, or more specifically ?loadable" - the classes must exist somewhere. Currently, in JDK 15, permittedSubclasses will return class descriptors for non-loadable classes. I think that this is ok, we just need to ensure that it fits into the other rules here. Yep. I think this is a good change, and I think there's nothing wrong with the reflection API either ignoring some entries or reporting class loading errors. Best to do whatever the NestMembers query does. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Wed Dec 2 17:59:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Dec 2020 17:59:56 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda wrote: > Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented). > > Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses(). > > Does this seem like a reasonable way to handle this corner case? I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype. If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From xuelei at openjdk.java.net Wed Dec 2 18:03:59 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Dec 2020 18:03:59 GMT Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources [v3] In-Reply-To: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com> References: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com> Message-ID: On Sun, 22 Nov 2020 18:27:56 GMT, Christoph Langer wrote: >> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829. >> >> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed. >> >> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close(). >> >> This problem can be reproduced by this code: >> SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket(); >> sslSocket.getSSLParameters(); >> sslSocket.close(); >> >> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer. >> >> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon. >> >> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected. >> >> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Small test improvement test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 57: > 55: if ((fds_end - fds_start) > (NUM_TEST_SOCK / 10)) { > 56: throw new RuntimeException("Too many open file descriptors. Looks leaky."); > 57: } This test case may be not reliable if there are some other test cases or applications running at the same time. It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted. test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 37: > 35: * will not leave leaking socket file descriptors > 36: * @library /test/lib > 37: * @run main/othervm SSLSocketLeak See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted. @run main/manual SSLSocketLeak ------------- PR: https://git.openjdk.java.net/jdk/pull/1363 From alanb at openjdk.java.net Wed Dec 2 18:32:01 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Dec 2020 18:32:01 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored Message-ID: The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. ------------- Commit messages: - Merge - Merge - Trailing whitespace - Expand test to Module attribute - Merge - Test cleanup - Add test - Merge - Reject classes with attribute length that doesn't match actual Changes: https://git.openjdk.java.net/jdk/pull/1407/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1407&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255542 Stats: 566 lines in 8 files changed: 562 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1407.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1407/head:pull/1407 PR: https://git.openjdk.java.net/jdk/pull/1407 From mchung at openjdk.java.net Wed Dec 2 18:32:01 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Dec 2020 18:32:01 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored In-Reply-To: References: Message-ID: <58VOzBNQesKJDDWsRg_WafXDmYmA3j7rsXQqibrp5wY=.8e10fdf0-3f9c-46ea-9b04-f6ce60e0231f@github.com> On Tue, 24 Nov 2020 10:58:43 GMT, Alan Bateman wrote: > The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. > > There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. Looks okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1407 From clanger at openjdk.java.net Wed Dec 2 18:44:57 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 2 Dec 2020 18:44:57 GMT Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources [v3] In-Reply-To: References: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com> Message-ID: On Wed, 2 Dec 2020 18:01:04 GMT, Xue-Lei Andrew Fan wrote: >> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: >> >> Small test improvement > > test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 37: > >> 35: * will not leave leaking socket file descriptors >> 36: * @library /test/lib >> 37: * @run main/othervm SSLSocketLeak > > See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted. > @run main/manual SSLSocketLeak Hm, I think it's fine as it is. Running it in othervm will make sure the test runs in its own vm (see http://openjdk.java.net/jtreg/command-help.html). So within the VM process there should not be any interference by other workload. And we check open files before testing and afterwards, and allow for some margin. The test has been running in our test setup for several days now, so I think it should be ok. And if worst comes to worse, and we see test noise, we might change the test to manual later on. ------------- PR: https://git.openjdk.java.net/jdk/pull/1363 From dfuchs at openjdk.java.net Wed Dec 2 18:50:00 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Dec 2020 18:50:00 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 10:58:43 GMT, Alan Bateman wrote: > The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. > > There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 288: > 286: > 287: long newPosition = in.count(); > 288: if (newPosition != (initialPosition + length)) { should this be: if ((newPosition - intialPosition) != length) { just to make it clear that no overflow can happen? ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From mcimadamore at openjdk.java.net Wed Dec 2 18:52:18 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Dec 2020 18:52:18 GMT Subject: RFR: 8257622: MemoryAccess methods are missing @ForceInline annotations Message-ID: The accessor methods in the `MemoryAccess` class are missing `@ForceInline` annotations. This causes odd behavior on certain benchmarks, especially if these methods are called many times in the body of a single method. ------------- Commit messages: - Add new benchmarks - Add @ForceInline annotations Changes: https://git.openjdk.java.net/jdk/pull/1570/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1570&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257622 Stats: 325 lines in 3 files changed: 325 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1570/head:pull/1570 PR: https://git.openjdk.java.net/jdk/pull/1570 From xuelei at openjdk.java.net Wed Dec 2 18:54:01 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Dec 2020 18:54:01 GMT Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources [v3] In-Reply-To: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com> References: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com> Message-ID: On Sun, 22 Nov 2020 18:27:56 GMT, Christoph Langer wrote: >> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829. >> >> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed. >> >> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close(). >> >> This problem can be reproduced by this code: >> SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket(); >> sslSocket.getSSLParameters(); >> sslSocket.close(); >> >> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer. >> >> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon. >> >> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected. >> >> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Small test improvement Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1363 From xuelei at openjdk.java.net Wed Dec 2 18:54:04 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Dec 2020 18:54:04 GMT Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources [v3] In-Reply-To: References: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com> Message-ID: On Wed, 2 Dec 2020 18:42:36 GMT, Christoph Langer wrote: >> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 37: >> >>> 35: * will not leave leaking socket file descriptors >>> 36: * @library /test/lib >>> 37: * @run main/othervm SSLSocketLeak >> >> See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted. >> @run main/manual SSLSocketLeak > > Hm, I think it's fine as it is. Running it in othervm will make sure the test runs in its own vm (see http://openjdk.java.net/jtreg/command-help.html). So within the VM process there should not be any interference by other workload. And we check open files before testing and afterwards, and allow for some margin. > > The test has been running in our test setup for several days now, so I think it should be ok. And if worst comes to worse, and we see test noise, we might change the test to manual later on. Sounds good to me. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1363 From alanb at openjdk.java.net Wed Dec 2 18:59:56 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Dec 2020 18:59:56 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:45:52 GMT, Daniel Fuchs wrote: >> The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. >> >> There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. > > src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 288: > >> 286: >> 287: long newPosition = in.count(); >> 288: if (newPosition != (initialPosition + length)) { > > should this be: > > if ((newPosition - intialPosition) != length) { > > just to make it clear that no overflow can happen? The attribute_length is a u4 so shouldn't arise but you are probably right that it would be clearer to reorganize it as you suggest. ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From github.com+66696993+nrakron at openjdk.java.net Wed Dec 2 19:03:00 2020 From: github.com+66696993+nrakron at openjdk.java.net (Narakron) Date: Wed, 2 Dec 2020 19:03:00 GMT Subject: RFR: 8257622: MemoryAccess methods are missing @ForceInline annotations In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:47:10 GMT, Maurizio Cimadamore wrote: > The accessor methods in the `MemoryAccess` class are missing `@ForceInline` annotations. This causes odd behavior on certain benchmarks, especially if these methods are called many times in the body of a single method. Marked as reviewed by Nrakron at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/1570 From clanger at openjdk.java.net Wed Dec 2 19:27:00 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 2 Dec 2020 19:27:00 GMT Subject: Integrated: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer wrote: > There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829. > > The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed. > > This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close(). > > This problem can be reproduced by this code: > SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket(); > sslSocket.getSSLParameters(); > sslSocket.close(); > > This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer. > > I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon. > > I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected. > > Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally. This pull request has now been integrated. Changeset: 93b6ab56 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/93b6ab56 Stats: 129 lines in 5 files changed: 97 ins; 15 del; 17 mod 8256818: SSLSocket that is never bound or connected leaks socket resources Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/1363 From prr at openjdk.java.net Wed Dec 2 19:29:55 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 2 Dec 2020 19:29:55 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ? If I read the doc below it is in the 10.10 SDK and later. https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From dlsmith at openjdk.java.net Wed Dec 2 19:34:59 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Wed, 2 Dec 2020 19:34:59 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:57:22 GMT, Mandy Chung wrote: > I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype. > > If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence). Agree, that seems reasonable. Often, methods in `Class` with an array return type default to an empty array, but `getRecordComponents` is a good example of returning `null` when an empty array is meaningful. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From akozlov at openjdk.java.net Wed Dec 2 20:06:59 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Dec 2020 20:06:59 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:27:25 GMT, Phil Race wrote: >> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. > > Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ? > If I read the doc below it is in the 10.10 SDK and later. > https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection. ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From prr at openjdk.java.net Wed Dec 2 20:22:55 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 2 Dec 2020 20:22:55 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote: >> Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ? >> If I read the doc below it is in the 10.10 SDK and later. >> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ > > Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection. I wonder if we should be "upping" that to something later. 10.9 is over 7 years old and has been out of support for what - 4 years ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From isipka at openjdk.java.net Wed Dec 2 20:27:58 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:27:58 GMT Subject: RFR: 8166026: refactor shell tests to java In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:36:40 GMT, Igor Ignatyev wrote: >> @iignatev could you please review? Thank you. >> >> note to self: >> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java > > test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java line 53: > >> 51: Files.createDirectories(REPOSITORY_PATH); >> 52: List classes = List.of("A.class", "B.class", "C.class"); >> 53: for (String fileName : classes) { > > is this really needed for the test to operate correctly? or can we just use _regular_ `TEST_CLASSES` as CP? CLASSES_PATH is initialized with value of TEST_CLASSES property. It is obviously confusing variable naming so in the [new PR](https://github.com/openjdk/jdk/pull/1577) it is renamed ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From isipka at openjdk.java.net Wed Dec 2 20:28:09 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:28:09 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java Message-ID: Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. ------------- Commit messages: - 8166026: Refactor java/lang shell tests to java Changes: https://git.openjdk.java.net/jdk/pull/1577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8166026 Stats: 501 lines in 6 files changed: 196 ins; 305 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From isipka at openjdk.java.net Wed Dec 2 20:33:08 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:33:08 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java Message-ID: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. ------------- Commit messages: - 8166026: Refactor java/lang shell tests to java Changes: https://git.openjdk.java.net/jdk/pull/1578/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8166026 Stats: 411 lines in 2 files changed: 206 ins; 205 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1578/head:pull/1578 PR: https://git.openjdk.java.net/jdk/pull/1578 From isipka at openjdk.java.net Wed Dec 2 20:33:56 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:33:56 GMT Subject: RFR: 8166026: refactor shell tests to java In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:32:35 GMT, Igor Ignatyev wrote: >> @iignatev could you please review? Thank you. >> >> note to self: >> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java > > test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java line 70: > >> 68: outputAnalyzer.shouldHaveExitValue(exitValue); >> 69: outputAnalyzer.stderrShouldMatch(stdErrMatch); >> 70: outputAnalyzer.stdoutShouldMatch(stdOutMatch); > > why do you use `ShouldMatch` and not `ShouldContain` here? Because the first two test input tuples are regular expressions, please see [new PR](https://github.com/openjdk/jdk/pull/1578) ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From isipka at openjdk.java.net Wed Dec 2 20:33:58 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:33:58 GMT Subject: RFR: 8166026: refactor shell tests to java In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 17:53:07 GMT, Roger Riggs wrote: >> @iignatev could you please review? Thank you. >> >> note to self: >> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java > > test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java line 40: > >> 38: */ >> 39: public class UncaughtExceptionsTest { >> 40: > > As with InheritIO, the nested classes that are invoked can be included in a single .java file. Refactored and moved to [new PR](https://github.com/openjdk/jdk/pull/1578) ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From javalists at cbfiddle.com Wed Dec 2 20:45:43 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 2 Dec 2020 12:45:43 -0800 Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: <4988ADB2-C1C2-4331-9D87-55C0A9A7B70A@cbfiddle.com> > On Dec 2, 2020, at 12:22 PM, Phil Race wrote: > > On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote: > >>> Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ? >>> If I read the doc below it is in the 10.10 SDK and later. >>> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ >> >> Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection. > > I wonder if we should be "upping" that to something later. > 10.9 is over 7 years old and has been out of support for what - 4 years ? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1569 > I know people running 10.10 and I try to keep my Java code running on 10.10, so I would suggest that. However, my experience is that JDK 14 and later refuse to run on 10.10. The metadata is conflicting: The Info.plist has JVMMinimumSystemVersion 10.6.0 libjli.dylib has LC_VERSION_MIN_MACOSX 10.9 However, libjvm has LC_VERSION_MIN_MACOSX 10.13, and that is enough to prevent it from running. From isipka at openjdk.java.net Wed Dec 2 20:50:13 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:50:13 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java Message-ID: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> Refactor `test/jdk/java/lang/SecurityManager/modules/CustomSecurityManager.sh` as java test. ------------- Commit messages: - 8166026: Refactor java/lang shell tests to java Changes: https://git.openjdk.java.net/jdk/pull/1579/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1579&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8166026 Stats: 173 lines in 3 files changed: 73 ins; 100 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1579/head:pull/1579 PR: https://git.openjdk.java.net/jdk/pull/1579 From isipka at openjdk.java.net Wed Dec 2 20:56:53 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 20:56:53 GMT Subject: RFR: 8256894: define test groups [v2] In-Reply-To: References: Message-ID: <1o3omJgGCa1crV2SbGqUsC_F9VgzjMqZyzlI9xF_PZQ=.9b3964dc-3314-4ef1-b08a-0d581b09afd7@github.com> On Mon, 30 Nov 2020 21:10:13 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257516: removing trailing space > > @frkator, you will need to open a new JBS ticket for this change. @iignatev as for: "https://github.com/openjdk/jdk/pull/1416#discussion_r532904345" accidentaly resolved. Yes they are but the goal is to list all manual tests under one label for counting purposes. Could you please assist with above? I assume it was due to some intermittent issue, I was able to build on the failed ones. ------------- PR: https://git.openjdk.java.net/jdk/pull/1416 From iignatyev at openjdk.java.net Wed Dec 2 21:17:55 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 2 Dec 2020 21:17:55 GMT Subject: RFR: 8256894: define test groups [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:10:13 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257516: removing trailing space > > @frkator, you will need to open a new JBS ticket for this change. > @iignatev as for: > "[#1416 (comment)](https://github.com/openjdk/jdk/pull/1416#discussion_r532904345)" > accidentaly resolved. Yes they are but the goal is to list all manual tests under one label for counting purposes. I understand that; my comment was rather to @AlanBateman 's request not to add manual tests into `:jdk_code`. they already are, and removing explicit inclusion of `:jdk_core_manual` to `:jdk_core` won't change that. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/1416 From jvernee at openjdk.java.net Wed Dec 2 21:27:53 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Dec 2020 21:27:53 GMT Subject: RFR: 8257622: MemoryAccess methods are missing @ForceInline annotations In-Reply-To: References: Message-ID: <8bFSKRC5KFcA8wjf9Dy98A7OTUQ1hjZCOLo7XYl1688=.72dc92be-b8de-4053-9d28-21e1af21aed0@github.com> On Wed, 2 Dec 2020 18:47:10 GMT, Maurizio Cimadamore wrote: > The accessor methods in the `MemoryAccess` class are missing `@ForceInline` annotations. This causes odd behavior on certain benchmarks, especially if these methods are called many times in the body of a single method. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1570 From isipka at openjdk.java.net Wed Dec 2 21:29:45 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 21:29:45 GMT Subject: RFR: 8166026: refactor shell tests to java [v2] In-Reply-To: References: Message-ID: > @iignatev could you please review? Thank you. > > note to self: > jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8166026: Refactor java/lang shell tests to java - 8166026:Refactor java/lang shell tests to java - 8166026: removing tab character - 8166026: refactor shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1484/files - new: https://git.openjdk.java.net/jdk/pull/1484/files/654cef82..16857464 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=00-01 Stats: 18532 lines in 441 files changed: 12661 ins; 3672 del; 2199 mod Patch: https://git.openjdk.java.net/jdk/pull/1484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1484/head:pull/1484 PR: https://git.openjdk.java.net/jdk/pull/1484 From akozlov at openjdk.java.net Wed Dec 2 21:35:57 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Dec 2020 21:35:57 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: On Wed, 2 Dec 2020 20:19:54 GMT, Phil Race wrote: >> Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection. > > I wonder if we should be "upping" that to something later. > 10.9 is over 7 years old and has been out of support for what - 4 years ? Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9 ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From isipka at openjdk.java.net Wed Dec 2 21:36:59 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 2 Dec 2020 21:36:59 GMT Subject: RFR: 8166026: refactor shell tests to java [v2] In-Reply-To: References: Message-ID: <6mtTFEfSwFLYRLDev3S-kxjxHysZaFk2vvRRwCl_leo=.8ebcf542-d4fe-4379-8f4b-bbe08429b10c@github.com> On Mon, 30 Nov 2020 17:44:13 GMT, Roger Riggs wrote: >> Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - 8166026: Refactor java/lang shell tests to java >> - 8166026:Refactor java/lang shell tests to java >> - 8166026: removing tab character >> - 8166026: refactor shell tests to java > > test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIo.java line 26: > >> 24: import static java.lang.ProcessBuilder.Redirect.*; >> 25: >> 26: class InheritIo { > > The rename of the class is unnecessary and less readable. > The function being tested is inheritIO and the test name should match. (As does the directory it is in). It is just one class now so there is no need for package either? I ran a rebase on this branch since deleting it would delete this PR also, I presume. So I deleted the files related to other tests which now have their own PR ([1](https://github.com/openjdk/jdk/pull/1579), [2](https://github.com/openjdk/jdk/pull/1578), [3](https://github.com/openjdk/jdk/pull/1577)) and made a diff to `master` (`HEAD` being `692b273ec53f54a879a4bbaad6c2f5f1d5358a71`): [JDK-8166026-refactor-shell-to-java] $ git diff --name-only open-mainline/master test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIO.java test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIO.sh test/jdk/java/lang/ProcessBuilder/InheritIOTest.java ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From vlivanov at openjdk.java.net Wed Dec 2 21:50:56 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 21:50:56 GMT Subject: Integrated: 8257164: Share LambdaForms for VH linkers/invokers In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov wrote: > Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers. > It reduces the number of LambdaForms needed at runtime. > > Testing: tier1-4 This pull request has now been integrated. Changeset: 7104400a Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/7104400a Stats: 48 lines in 3 files changed: 21 ins; 10 del; 17 mod 8257164: Share LambdaForms for VH linkers/invokers Reviewed-by: redestad, kvn, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/1455 From erikj at openjdk.java.net Wed Dec 2 21:59:55 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Dec 2020 21:59:55 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: On Wed, 2 Dec 2020 21:32:46 GMT, Anton Kozlov wrote: >> I wonder if we should be "upping" that to something later. >> 10.9 is over 7 years old and has been out of support for what - 4 years ? > > Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9 The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used. So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4. The discrepancy in Info.plist was fixed in JDK-8252145. ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From erikj at openjdk.java.net Wed Dec 2 22:03:54 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Dec 2020 22:03:54 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: On Wed, 2 Dec 2020 21:57:15 GMT, Erik Joelsson wrote: >> Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9 > > The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used. > > So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4. > > The discrepancy in Info.plist was fixed in JDK-8252145. We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From erikj at openjdk.java.net Wed Dec 2 22:06:55 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Dec 2020 22:06:55 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: On Wed, 2 Dec 2020 22:00:55 GMT, Erik Joelsson wrote: >> The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used. >> >> So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4. >> >> The discrepancy in Info.plist was fixed in JDK-8252145. > > We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug. Filed https://bugs.openjdk.java.net/browse/JDK-8257633 ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From ccheung at openjdk.java.net Wed Dec 2 22:10:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 2 Dec 2020 22:10:13 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v5] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: Skip testing with default CDS archive on aarch64 platform ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/fc10e77f..ec851f0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=03-04 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Wed Dec 2 22:21:02 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 2 Dec 2020 22:21:02 GMT Subject: Integrated: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) This pull request has now been integrated. Changeset: 3da30e99 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/3da30e99 Stats: 193 lines in 9 files changed: 135 ins; 16 del; 42 mod 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes Reviewed-by: iklam, redestad, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From smarks at openjdk.java.net Thu Dec 3 01:16:01 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Dec 2020 01:16:01 GMT Subject: RFR: 8228615: Optional.empty doc should suggest using isEmpty Message-ID: Some small doc changes. The changes are to `@apiNote` text, which is non-normative, so no CSR is required. ------------- Commit messages: - 8228615: Optional.empty() doc should suggest isEmpty() instead of isPresent() Changes: https://git.openjdk.java.net/jdk/pull/1585/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1585&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228615 Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1585.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1585/head:pull/1585 PR: https://git.openjdk.java.net/jdk/pull/1585 From lancea at openjdk.java.net Thu Dec 3 01:26:56 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Dec 2020 01:26:56 GMT Subject: RFR: 8228615: Optional.empty doc should suggest using isEmpty In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 01:08:18 GMT, Stuart Marks wrote: > Some small doc changes. The changes are to `@apiNote` text, which is non-normative, so no CSR is required. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1585 From bpb at openjdk.java.net Thu Dec 3 01:36:57 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 3 Dec 2020 01:36:57 GMT Subject: RFR: 8228615: Optional.empty doc should suggest using isEmpty In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 01:08:18 GMT, Stuart Marks wrote: > Some small doc changes. The changes are to `@apiNote` text, which is non-normative, so no CSR is required. +1 ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1585 From naoto at openjdk.java.net Thu Dec 3 01:39:54 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Dec 2020 01:39:54 GMT Subject: RFR: 8228615: Optional.empty doc should suggest using isEmpty In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 01:08:18 GMT, Stuart Marks wrote: > Some small doc changes. The changes are to `@apiNote` text, which is non-normative, so no CSR is required. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1585 From akozlov at openjdk.java.net Thu Dec 3 06:52:55 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 3 Dec 2020 06:52:55 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: On Wed, 2 Dec 2020 22:04:17 GMT, Erik Joelsson wrote: >> We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug. > > Filed https://bugs.openjdk.java.net/browse/JDK-8257633 Thanks for taking care of those issues. To be clear, there is no real need to bump the version for this PR, 10.9 is fine. This PR just proposes another way to implement the workaround for 10.9. ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From jlahoda at openjdk.java.net Thu Dec 3 09:22:18 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Dec 2020 09:22:18 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v5] In-Reply-To: References: Message-ID: > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Blank lines do not count for the text block indentation, removing them. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1480/files - new: https://git.openjdk.java.net/jdk/pull/1480/files/9ab7153a..3aaaf28c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=03-04 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480 From jlahoda at openjdk.java.net Thu Dec 3 09:39:57 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Dec 2020 09:39:57 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:06:25 GMT, Jan Lahoda wrote: >> test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513: >> >>> 511: public java.util.List l(); >>> 512: } >>> 513: """, >> >> I don't understand why the lines with `\n` in a text block > > There is a combination of factors here: > -jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks > -textblocks only remove indentation that is common on all lines. > > So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list): > -do some trick to have the common indent, but no trailing whitespace. '\n' is one of them. > -not indent the text block > -do some post-processing on the text block's value or the actual test output, to make them match > -not use textblocks I stand corrected here - blank lines do not count when the common indent is computed. Removed here: https://github.com/openjdk/jdk/pull/1480/commits/3aaaf28c23ddda71c77ca9923e02e5f3502cde3b ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From alanb at openjdk.java.net Thu Dec 3 09:58:16 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 3 Dec 2020 09:58:16 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: > The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. > > There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Restructure check to make it more obvious that it doesn't overflow - Merge - Merge - Merge - Trailing whitespace - Expand test to Module attribute - Merge - Test cleanup - Add test - Merge - ... and 1 more: https://git.openjdk.java.net/jdk/compare/1586643c...f15dbb1b ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1407/files - new: https://git.openjdk.java.net/jdk/pull/1407/files/600db8cf..f15dbb1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1407&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1407&range=00-01 Stats: 4917 lines in 168 files changed: 4255 ins; 240 del; 422 mod Patch: https://git.openjdk.java.net/jdk/pull/1407.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1407/head:pull/1407 PR: https://git.openjdk.java.net/jdk/pull/1407 From dfuchs at openjdk.java.net Thu Dec 3 10:21:03 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Dec 2020 10:21:03 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 09:58:16 GMT, Alan Bateman wrote: >> The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. >> >> There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Restructure check to make it more obvious that it doesn't overflow > - Merge > - Merge > - Merge > - Trailing whitespace > - Expand test to Module attribute > - Merge > - Test cleanup > - Add test > - Merge > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/03216be8...f15dbb1b Marked as reviewed by dfuchs (Reviewer). src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 288: > 286: > 287: long newPosition = in.count(); > 288: if ((newPosition - initialPosition) != length) { LGTM! Thanks for making the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From jboes at openjdk.java.net Thu Dec 3 10:45:08 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Dec 2020 10:45:08 GMT Subject: RFR: 8257591: Remove suppression of record preview related warnings in java.lang Message-ID: Records exit preview in JDK 16. This change removes preview related suppression warnings in some source files and removes the '--enable-preview' option for compilation and execution of some tests that use record classes. ------------- Commit messages: - remove --enable-preview in tests - remove record related warning suppression Changes: https://git.openjdk.java.net/jdk/pull/1591/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1591&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257591 Stats: 16 lines in 6 files changed: 0 ins; 6 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1591/head:pull/1591 PR: https://git.openjdk.java.net/jdk/pull/1591 From chegar at openjdk.java.net Thu Dec 3 11:12:56 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 3 Dec 2020 11:12:56 GMT Subject: RFR: 8257591: Remove suppression of record preview related warnings in java.lang In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 10:39:05 GMT, Julia Boes wrote: > Records exit preview in JDK 16. This change removes preview related suppression warnings in some source files and removes the '--enable-preview' option for compilation and execution of some tests that use record classes. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1591 From chegar at openjdk.java.net Thu Dec 3 12:30:03 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 3 Dec 2020 12:30:03 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 09:58:16 GMT, Alan Bateman wrote: >> The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. >> >> There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Restructure check to make it more obvious that it doesn't overflow > - Merge > - Merge > - Merge > - Trailing whitespace > - Expand test to Module attribute > - Merge > - Test cleanup > - Add test > - Merge > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/575caaeb...f15dbb1b Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From github.com+828220+forax at openjdk.java.net Thu Dec 3 12:54:09 2020 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 3 Dec 2020 12:54:09 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 09:58:16 GMT, Alan Bateman wrote: >> The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. >> >> There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Restructure check to make it more obvious that it doesn't overflow > - Merge > - Merge > - Merge > - Trailing whitespace > - Expand test to Module attribute > - Merge > - Test cleanup > - Add test > - Merge > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/914dd7e9...f15dbb1b src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 1203: > 1201: @Override > 1202: public String readUTF() throws IOException { > 1203: return DataInputStream.readUTF(this); If i understand correctly the code, I believe readUTF should change a boolean field named `countCanNotBeTrackedAnymore` from false to true, and in the method `count()`, `countCanNotBeTrackedAnymore` has to be checked and throws an ISE before returning `count` ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From jlahoda at openjdk.java.net Thu Dec 3 14:09:10 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Dec 2020 14:09:10 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v4] In-Reply-To: References: Message-ID: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Fixing tests. - getPermittedSubclasses to return null for non-sealed classes, as requested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1483/files - new: https://git.openjdk.java.net/jdk/pull/1483/files/ff1abf06..537e267f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=02-03 Stats: 117 lines in 6 files changed: 94 ins; 5 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483 PR: https://git.openjdk.java.net/jdk/pull/1483 From jlahoda at openjdk.java.net Thu Dec 3 14:11:57 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Dec 2020 14:11:57 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:31:59 GMT, Dan Smith wrote: >>> Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented). >>> >>> Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses(). >>> >>> Does this seem like a reasonable way to handle this corner case? >> >> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype. >> >> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence). > >> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype. >> >> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence). > > Agree, that seems reasonable. Often, methods in `Class` with an array return type default to an empty array, but `getRecordComponents` is a good example of returning `null` when an empty array is meaningful. I've changed Class.getPermittedSubclasses to return null for classes that are not sealed here: https://github.com/openjdk/jdk/pull/1483/commits/7056143822ff62dfbb1d294c67352ed3892317c2 with follow-up changes to tests here: https://github.com/openjdk/jdk/pull/1483/commits/537e267fb6802ab5cf38bf26978039383cc6309a How does this look? ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mullan at openjdk.java.net Thu Dec 3 14:17:56 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 3 Dec 2020 14:17:56 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java In-Reply-To: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> References: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> Message-ID: On Wed, 2 Dec 2020 20:45:11 GMT, Ivan ?ipka wrote: > Refactor `test/jdk/java/lang/SecurityManager/modules/CustomSecurityManager.sh` as java test. Marked as reviewed by mullan (Reviewer). test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java line 2: > 1: /* > 2: * Copyright (c) 2015, 2020 Oracle and/or its affiliates. All rights reserved. You are missing a comma after "2020". ------------- PR: https://git.openjdk.java.net/jdk/pull/1579 From jlahoda at openjdk.java.net Thu Dec 3 14:40:55 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Dec 2020 14:40:55 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 14:08:48 GMT, Jan Lahoda wrote: >>> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype. >>> >>> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence). >> >> Agree, that seems reasonable. Often, methods in `Class` with an array return type default to an empty array, but `getRecordComponents` is a good example of returning `null` when an empty array is meaningful. > > I've changed Class.getPermittedSubclasses to return null for classes that are not sealed here: > https://github.com/openjdk/jdk/pull/1483/commits/7056143822ff62dfbb1d294c67352ed3892317c2 > with follow-up changes to tests here: > https://github.com/openjdk/jdk/pull/1483/commits/537e267fb6802ab5cf38bf26978039383cc6309a > > How does this look? After a discussion with Harold, I've reverted the patch where Class.getPermittedSubclasses returns null. Harold will do that separatelly under JDK-8256867, unless there are objections. The changes that were reverted are still available here: https://openjdk.github.io/cr/?repo=jdk&pr=1483&range=02-03 Please let me know if there are any issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From github.com+1709517+mariusvolkhart at openjdk.java.net Thu Dec 3 14:47:04 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Thu, 3 Dec 2020 14:47:04 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event Message-ID: The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. ------------- Commit messages: - Merge pull request #1 from jerboaa/pull-1056-amend - Adjust test so it works with jtreg - Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event - Add test for XmlInputFactory Changes: https://git.openjdk.java.net/jdk/pull/1056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1056&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256515 Stats: 47 lines in 2 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1056/head:pull/1056 PR: https://git.openjdk.java.net/jdk/pull/1056 From sgehwolf at openjdk.java.net Thu Dec 3 14:47:04 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 3 Dec 2020 14:47:04 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 14:01:53 GMT, Marius Volkhart wrote: > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. @MariusVolkhart I'll work with you getting the fix in and get the test running using jtreg. Give me a few moments to reproduce. ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From github.com+1709517+mariusvolkhart at openjdk.java.net Thu Dec 3 14:47:04 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Thu, 3 Dec 2020 14:47:04 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 09:42:49 GMT, Severin Gehwolf wrote: >> The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. >> >> The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. > > @MariusVolkhart I'll work with you getting the fix in and get the test running using jtreg. Give me a few moments to reproduce. Thanks @jerboaa I have a JBS number now: [8256515](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8256515). Since opening the PR I've learned that I've gone about the process backwards, and should have found a Sponsor before making the PR. As such, I haven't updated the commit message to avoid sending a premature RFR to the mailing list ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From joehw at openjdk.java.net Thu Dec 3 14:47:04 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 3 Dec 2020 14:47:04 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:34:36 GMT, Marius Volkhart wrote: >> @MariusVolkhart I'll work with you getting the fix in and get the test running using jtreg. Give me a few moments to reproduce. > > Thanks @jerboaa > > I have a JBS number now: [8256515](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8256515). Since opening the PR I've learned that I've gone about the process backwards, and should have found a Sponsor before making the PR. As such, I haven't updated the commit message to avoid sending a premature RFR to the mailing list Hi Marius, Saw the JBS issue, pls edit the title to sth. like the following: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event Thanks, Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From sgehwolf at openjdk.java.net Thu Dec 3 14:47:04 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 3 Dec 2020 14:47:04 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:34:36 GMT, Marius Volkhart wrote: >> @MariusVolkhart I'll work with you getting the fix in and get the test running using jtreg. Give me a few moments to reproduce. > > Thanks @jerboaa > > I have a JBS number now: [8256515](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8256515). Since opening the PR I've learned that I've gone about the process backwards, and should have found a Sponsor before making the PR. As such, I haven't updated the commit message to avoid sending a premature RFR to the mailing list @MariusVolkhart I think doing a PR is fine before you find a sponsor provided you're fairly certain it's an actual bug. It'll require one to then send an email to the mailing lists asking for a sponsor. That email could potentially reference a PR. That should be fine. The sponsor (committer) will then help you get it integrated. It somewhat depends on the issue. No hard-and-fast rules that I'm aware of in that regard. @MariusVolkhart Here is a PR for your branch so the test works with jtreg: https://github.com/MariusVolkhart/jdk/pull/1 Fails before the JDK patch and passes after. Run it with: $ rm -rf JTwork JTreport && jtreg -jdk:./build/linux-x86_64-server-release/images/jdk -verbose:summary test/jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java Passed: javax/xml/jaxp/8256515/XmlInputFactoryTest.java Test results: passed: 1 Results are in *.jtr files: $ find JTwork/ -name *.jtr JTwork/javax/xml/jaxp/8256515/XmlInputFactoryTest.jtr Or using the test framework of OpenJDK with: $ bash configure --with-jtreg=/path/to/jtreg [...] $ make test TEST="jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java" HTH ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From github.com+1709517+mariusvolkhart at openjdk.java.net Thu Dec 3 14:47:05 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Thu, 3 Dec 2020 14:47:05 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 11:41:53 GMT, Severin Gehwolf wrote: >> Thanks @jerboaa >> >> I have a JBS number now: [8256515](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8256515). Since opening the PR I've learned that I've gone about the process backwards, and should have found a Sponsor before making the PR. As such, I haven't updated the commit message to avoid sending a premature RFR to the mailing list > > @MariusVolkhart Here is a PR for your branch so the test works with jtreg: > https://github.com/MariusVolkhart/jdk/pull/1 > > Fails before the JDK patch and passes after. > > Run it with: > $ rm -rf JTwork JTreport && jtreg -jdk:./build/linux-x86_64-server-release/images/jdk -verbose:summary test/jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java > Passed: javax/xml/jaxp/8256515/XmlInputFactoryTest.java > Test results: passed: 1 > Results are in *.jtr files: > > $ find JTwork/ -name *.jtr > JTwork/javax/xml/jaxp/8256515/XmlInputFactoryTest.jtr > > Or using the test framework of OpenJDK with: > > $ bash configure --with-jtreg=/path/to/jtreg [...] > $ make test TEST="jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java" > > HTH @jerboaa Thanks! That PR was immensely helpful, not just in helping get this change moving, but in helping me understand how to write the tests for next time! ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From github.com+1709517+mariusvolkhart at openjdk.java.net Thu Dec 3 14:47:05 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Thu, 3 Dec 2020 14:47:05 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: <9Zx4gqDqSzqR4TR_eE_-Vn55k47pBJJrYEeBLjUuaMc=.2e57b186-4e24-4196-881b-638c26b9864b@github.com> On Wed, 4 Nov 2020 14:01:53 GMT, Marius Volkhart wrote: > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. test/jdk/javax/xml/stream/XmlInputFactoryTest.java line 12: > 10: import static org.testng.Assert.assertTrue; > 11: > 12: public class XmlInputFactoryTest { This test is written correctly for regular TestNG, but I don't know if it's "right" for jtreg. I'm happy to make any changes necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From ewhelan at openjdk.java.net Thu Dec 3 15:15:03 2020 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 3 Dec 2020 15:15:03 GMT Subject: RFR: 8255845: Memory leak in imageFile.cpp Message-ID: This is a straightforward fix to resolve a potential memory leak in imageFile.cpp. If `find_location` returns true, the `path` char array is never released. This has been fixed ------------- Commit messages: - 8255845: Memory leak in imageFile.cpp Changes: https://git.openjdk.java.net/jdk/pull/1599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255845 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1599/head:pull/1599 PR: https://git.openjdk.java.net/jdk/pull/1599 From jlaskey at openjdk.java.net Thu Dec 3 15:18:56 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 3 Dec 2020 15:18:56 GMT Subject: RFR: 8255845: Memory leak in imageFile.cpp In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 14:57:16 GMT, Evan Whelan wrote: > This is a straightforward fix to resolve a potential memory leak in imageFile.cpp. > > If `find_location` returns true, the `path` char array is never released. > > This has been fixed Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1599 From sundar at openjdk.java.net Thu Dec 3 15:25:56 2020 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 3 Dec 2020 15:25:56 GMT Subject: RFR: 8255845: Memory leak in imageFile.cpp In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 14:57:16 GMT, Evan Whelan wrote: > This is a straightforward fix to resolve a potential memory leak in imageFile.cpp. > > If `find_location` returns true, the `path` char array is never released. > > This has been fixed Marked as reviewed by sundar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1599 From ewhelan at openjdk.java.net Thu Dec 3 15:34:58 2020 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 3 Dec 2020 15:34:58 GMT Subject: Integrated: 8255845: Memory leak in imageFile.cpp In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 14:57:16 GMT, Evan Whelan wrote: > This is a straightforward fix to resolve a potential memory leak in imageFile.cpp. > > If `find_location` returns true, the `path` char array is never released. > > This has been fixed This pull request has now been integrated. Changeset: 66a2e709 Author: Evan Whelan Committer: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/66a2e709 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8255845: Memory leak in imageFile.cpp Reviewed-by: jlaskey, sundar ------------- PR: https://git.openjdk.java.net/jdk/pull/1599 From jboes at openjdk.java.net Thu Dec 3 15:50:57 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Dec 2020 15:50:57 GMT Subject: Integrated: 8257591: Remove suppression of record preview related warnings in java.lang In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 10:39:05 GMT, Julia Boes wrote: > Records exit preview in JDK 16. This change removes preview related suppression warnings in some source files and removes the '--enable-preview' option for compilation and execution of some tests that use record classes. This pull request has now been integrated. Changeset: b170c837 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/b170c837 Stats: 16 lines in 6 files changed: 0 ins; 6 del; 10 mod 8257591: Remove suppression of record preview related warnings in java.lang Reviewed-by: chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1591 From dfuchs at openjdk.java.net Thu Dec 3 15:54:59 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Dec 2020 15:54:59 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:50:56 GMT, R?mi Forax wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Restructure check to make it more obvious that it doesn't overflow >> - Merge >> - Merge >> - Merge >> - Trailing whitespace >> - Expand test to Module attribute >> - Merge >> - Test cleanup >> - Add test >> - Merge >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/5bb86f87...f15dbb1b > > src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 1203: > >> 1201: @Override >> 1202: public String readUTF() throws IOException { >> 1203: return DataInputStream.readUTF(this); > > If i understand correctly the code, I believe readUTF should change a boolean field named `countCanNotBeTrackedAnymore` from false to true, and in the method `count()`, `countCanNotBeTrackedAnymore` has to be checked and throws an ISE before returning `count` Hi R?mi, I do not think that that is required. `DataInputStream.readUTF` will call back into `this` to do the reading so the `count` should be properly incremented? Or maybe I'm missing something. Best regards! ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From github.com+828220+forax at openjdk.java.net Thu Dec 3 15:59:00 2020 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 3 Dec 2020 15:59:00 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 15:52:35 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 1203: >> >>> 1201: @Override >>> 1202: public String readUTF() throws IOException { >>> 1203: return DataInputStream.readUTF(this); >> >> If i understand correctly the code, I believe readUTF should change a boolean field named `countCanNotBeTrackedAnymore` from false to true, and in the method `count()`, `countCanNotBeTrackedAnymore` has to be checked and throws an ISE before returning `count` > > Hi R?mi, I do not think that that is required. `DataInputStream.readUTF` will call back into `this` to do the reading so the `count` should be properly incremented? Or maybe I'm missing something. Best regards! Thanks, i should have read the code more carefully. ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From alanb at openjdk.java.net Thu Dec 3 15:59:00 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 3 Dec 2020 15:59:00 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 15:55:15 GMT, R?mi Forax wrote: >> Hi R?mi, I do not think that that is required. `DataInputStream.readUTF` will call back into `this` to do the reading so the `count` should be properly incremented? Or maybe I'm missing something. Best regards! > > Thanks, > i should have read the code more carefully. The module-info is read sequentially so the constant pool is read (and indexed) before the attributes are read. So any references to UTF-8 constants doesn't involve random access. But maybe you mean something else? ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From lfoltan at openjdk.java.net Thu Dec 3 16:09:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 3 Dec 2020 16:09:57 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 14:40:15 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback. I reviewed the hotspot changes and they hotspot look good. Thanks, Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1483 From shade at openjdk.java.net Thu Dec 3 17:21:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 17:21:58 GMT Subject: RFR: 8257622: MemoryAccess methods are missing @ForceInline annotations In-Reply-To: References: Message-ID: <7MIMS2qlSVzWZKN3U3Q0UBauOoYqdsBTcKZrj_sHN9M=.c25e797a-0177-4dd8-9769-441bd43488c0@github.com> On Wed, 2 Dec 2020 18:47:10 GMT, Maurizio Cimadamore wrote: > The accessor methods in the `MemoryAccess` class are missing `@ForceInline` annotations. This causes odd behavior on certain benchmarks, especially if these methods are called many times in the body of a single method. Looks good with minor nit. test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantFP.java line 72: > 70: unsafe_addrOut = unsafe.allocateMemory(ALLOC_SIZE); > 71: for (int i = 0; i < ELEM_SIZE; i++) { > 72: unsafe.putDouble(unsafe_addrIn + (i * CARRIER_SIZE) , i); Here and later, excess whitespace before final comma. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1570 From mchung at openjdk.java.net Thu Dec 3 17:26:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 17:26:57 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 16:07:28 GMT, Lois Foltan wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback. > > I have reviewed the hotspot changes and they look good. > Thanks, > Lois > After a discussion with Harold, I've reverted the patch where Class.getPermittedSubclasses returns null. Harold will do that separatelly under JDK-8256867, unless there are objections. No objection. Keeping `Class::getPermittedSubclasses` as specified in the CSR is right thing to do so that this work can be integrated and resolve JDK-8256867 separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Thu Dec 3 17:29:02 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 17:29:02 GMT Subject: RFR: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored [v2] In-Reply-To: References: Message-ID: <3J4fxHRZbcUlY2ovLE5KI9l713OJjYD3yYgX8EwUws0=.5d97a4ee-c808-4f7b-93e5-cb1a10a9016f@github.com> On Thu, 3 Dec 2020 09:58:16 GMT, Alan Bateman wrote: >> The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. >> >> There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Restructure check to make it more obvious that it doesn't overflow > - Merge > - Merge > - Merge > - Trailing whitespace > - Expand test to Module attribute > - Merge > - Test cleanup > - Add test > - Merge > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/46ea739e...f15dbb1b Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From mchung at openjdk.java.net Thu Dec 3 18:21:00 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 18:21:00 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 14:40:15 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback. I approve this version of `Class::getPermittedSubclasses` implementation for this PR. We need to follow up the specification of `Class::getPermittedSubclasses` w.r.t. what it should return e.g. the classes whatever in `PermittedSubclasses` attribute vs the classes that are permitted subtypes at runtime and return null if this class is not sealed. I reviewed hotspot and java.base changes (not langtools) with a couple minor comments. test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 51: > 49: public class TestSecurityManagerChecks { > 50: > 51: private static final ClassLoader OBJECT_CL = Object.class.getClassLoader(); This is `null` - the bootstrap class loader. An alternative to the static variable we can simply use null. test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 66: > 64: .getProtectionDomain() > 65: .getCodeSource() > 66: .getLocation(); This is essentially the classpath. An alternative way to get the location through `System.getProperty("test.class.path")`. test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 86: > 84: > 85: // First get hold of the target classes before we enable security > 86: Class sealed = testLayer.findLoader("test").loadClass("test.Base"); I would recommend to use `Class::forName` instead of `ClassLoader::loadClass` even though this is just a test (for security reason for example avoid type confusion). If you want to load a class from a specific module, you can use `Class.forName(String cn, Module m)` test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 91: > 89: Class[] subclasses = sealed.getPermittedSubclasses(); > 90: > 91: if (subclasses.length != 3) { I suggest to check against the expected list of permitted subclasses here and also the validation in the subsequent calls to `getPermittedSubclasses` with security manager enabled. That would help the readers easier to understand this test. test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 120: > 118: > 119: //should pass - does not return a class from package "test": > 120: sealed.getPermittedSubclasses(); Adding a check to the expected returned value would make this clear (no permitted subclasses of package `test`). src/java.base/share/classes/java/lang/Class.java line 3035: > 3033: */ > 3034: private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm, > 3035: final ClassLoader ccl, boolean checkProxyInterfaces, `checkProxyInterfaces` parameter is not needed. It can be removed. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Thu Dec 3 19:16:02 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 19:16:02 GMT Subject: RFR: 8235784: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java fails due to timeout with fastdebug bits Message-ID: VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build and slow mac os machines. I can't reproduce this locally. It fails on jdk 16 internal testing on a few builds. I propose to increase the timeout and see if that is adequate or not. We will re-examine this test if the increased timeout is not adequate. ------------- Commit messages: - 8235784: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java fails due to timeout with fastdebug bits Changes: https://git.openjdk.java.net/jdk/pull/1603/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1603&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235784 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1603.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1603/head:pull/1603 PR: https://git.openjdk.java.net/jdk/pull/1603 From isipka at openjdk.java.net Thu Dec 3 19:29:10 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 3 Dec 2020 19:29:10 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> References: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> Message-ID: <3pE186Ftq4YaoXn8-XDFjcFoXDDG0JJf2TmveY8jFBs=.d094e8bb-54c2-4210-98a6-5169555ac439@github.com> > Refactor `test/jdk/java/lang/SecurityManager/modules/CustomSecurityManager.sh` as java test. Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision: - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1579/files - new: https://git.openjdk.java.net/jdk/pull/1579/files/6968fee1..ca546c65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1579&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1579&range=00-01 Stats: 17 lines in 1 file changed: 12 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1579/head:pull/1579 PR: https://git.openjdk.java.net/jdk/pull/1579 From isipka at openjdk.java.net Thu Dec 3 19:33:14 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 3 Dec 2020 19:33:14 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/bc56a637..3a832a4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From smarks at openjdk.java.net Thu Dec 3 19:35:55 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Dec 2020 19:35:55 GMT Subject: Integrated: 8228615: Optional.empty doc should suggest using isEmpty In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 01:08:18 GMT, Stuart Marks wrote: > Some small doc changes. The changes are to `@apiNote` text, which is non-normative, so no CSR is required. This pull request has now been integrated. Changeset: 2b73f992 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/2b73f992 Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod 8228615: Optional.empty doc should suggest using isEmpty Reviewed-by: lancea, bpb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/1585 From isipka at openjdk.java.net Thu Dec 3 19:37:11 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 3 Dec 2020 19:37:11 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: > Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1578/files - new: https://git.openjdk.java.net/jdk/pull/1578/files/4bd57942..fa23de7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1578/head:pull/1578 PR: https://git.openjdk.java.net/jdk/pull/1578 From isipka at openjdk.java.net Thu Dec 3 19:46:14 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 3 Dec 2020 19:46:14 GMT Subject: RFR: 8166026: refactor shell tests to java [v3] In-Reply-To: References: Message-ID: > @iignatev could you please review? Thank you. > > note to self: > jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1484/files - new: https://git.openjdk.java.net/jdk/pull/1484/files/16857464..75096d42 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1484/head:pull/1484 PR: https://git.openjdk.java.net/jdk/pull/1484 From smarks at openjdk.java.net Thu Dec 3 21:06:56 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Dec 2020 21:06:56 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: <_xofj9Juf4O7Mgi0GTuK81yn_91FD0d2g3Fe6eExBXg=.39a225aa-201d-46e7-8b08-cc6657574f87@github.com> References: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com> <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> <_xofj9Juf4O7Mgi0GTuK81yn_91FD0d2g3Fe6eExBXg=.39a225aa-201d-46e7-8b08-cc6657574f87@github.com> Message-ID: <0kiMjbIbBrNJdOhrK6JzEZ6jn72lgKVtyR_lOfJiscc=.0ae2dab5-cbd0-4c3d-800a-615ed700bb32@github.com> On Mon, 30 Nov 2020 15:08:51 GMT, Pavel Rappo wrote: >> @johnlinp, thanks for updating the CSR draft; it is much better now. >> >> @stuart-marks, I think we could further improve this snippet. This `if` statement seems to use an optimization: >> >> if (oldValue != null || map.containsKey(key)) >> >> I don't think we should include an optimization into the specification unless that optimization also improves readability. Is this the case here? Could this be better? >> >> if (map.containsKey(key)) > > I would even go as far as to rewrite that snippet like this: > > if (newValue == null) { > remove(key); > } else { > put(key, newValue); > } > return newValue; > > This rewrite is possible thanks to the following properties of `Map.remove(Object key)`: > > 1. A call with an unmapped `key` has no effect. > 2. A call with a mapped `key` has the same semantics regardless of the value that this key is mapped to. > > In particular, (2) covers `null` values. > > To me, this rewrite reads better; however, I understand that readability is subjective and that snippets used in `@implSpec` might be subject to additional requirements. @pavelrappo The intended effect of the revised snippet is sensible, but again I note that it differs from the actual default implementation. Specifically: if the map does not contain the key and newValue is null, the default implementation currently does nothing, whereas the revised snippet calls `remove(key)`. This should have no effect _on the map_ but a subclass might override `remove` and this behavior difference is observable. (The typical example of this is maintaining a counter of the number of operations. I think _Effective Java_ uses that example in discussing subclassing.) I think the main priority here is fidelity to what the default implementation actually does -- at least, concerning operations on *this* -- and less on readability. ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From smarks at openjdk.java.net Thu Dec 3 21:16:55 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Dec 2020 21:16:55 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> References: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com> <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> Message-ID: On Sat, 28 Nov 2020 08:42:52 GMT, John Lin wrote: >> @johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this: >> returning the current value or {@code null} if absent:``` > > @pavelrappo Please see my updated CSR below. Thanks. > > # Map::compute should have the implementation requirement match its default implementation > > ## Summary > > The implementation requirement of Map::compute does not match its default implementation. Besides, it has some other minor issues. We should fix it. > > ## Problem > > The documentation of the implementation requirements for Map::compute has the following problems: > 1. It doesn't match its default implementation. > 1. It lacks of the return statements for most of the if-else cases. > 1. The indents are 3 spaces, while the convention is 4 spaces. > 1. The if-else is overly complicated and can be simplified. > 1. The surrounding prose contains incorrect statements. > > ## Solution > > Rewrite the documentation of Map::compute to match its default implementation and solve the above mentioned problems. > > ## Specification > > diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java > index b1de34b42a5..b30e3979259 100644 > --- a/src/java.base/share/classes/java/util/Map.java > +++ b/src/java.base/share/classes/java/util/Map.java > @@ -1107,23 +1107,17 @@ public interface Map { > * > * @implSpec > * The default implementation is equivalent to performing the following > - * steps for this {@code map}, then returning the current value or > - * {@code null} if absent: > + * steps for this {@code map}: > * > * 

 {@code
>       * V oldValue = map.get(key);
>       * V newValue = remappingFunction.apply(key, oldValue);
> -     * if (oldValue != null) {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       map.remove(key);
> -     * } else {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       return null;
> +     * if (newValue != null) {
> +     *     map.put(key, newValue);
> +     * } else if (oldValue != null || map.containsKey(key)) {
> +     *     map.remove(key);
>       * }
> +     * return newValue;
>       * }
> * > *

The default implementation makes no guarantees about detecting if the The current snippet proposed by @johnlinp does seem to have the same behavior as the default implementation; I would avoid trying to "optimize" this. However, it does express the conditions and return value somewhat differently from the way the default implementation does. I think those differences are not significant to subclasses and are mostly stylistic. The original `@implSpec` snippet attempted to handle the cases separately, whereas the current proposed snippet minimizes them (while still agreeing with the implementation's behavior). I'm not too concerned about this. I think the current snippet is acceptable. Again, the main priority is agreement with the implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From rriggs at openjdk.java.net Thu Dec 3 21:45:01 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 3 Dec 2020 21:45:01 GMT Subject: RFR: 8166026: refactor shell tests to java [v3] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 19:46:14 GMT, Ivan ?ipka wrote: >> @iignatev could you please review? Thank you. >> >> note to self: >> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From rriggs at openjdk.java.net Thu Dec 3 21:52:56 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 3 Dec 2020 21:52:56 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: On Thu, 3 Dec 2020 19:37:11 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java Please rename the class Seppuku to a more generic name for a process that exits as the result of an uncaught exception. Perhaps a simple "UncaughtExit". ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1578 From rriggs at openjdk.java.net Thu Dec 3 22:05:00 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 3 Dec 2020 22:05:00 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 19:33:14 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java Changes requested by rriggs (Reviewer). test/jdk/java/lang/annotation/LoaderLeakTest.java line 65: > 63: @Test > 64: public void testWithoutReadingAnnotations() throws Throwable { > 65: runJavaProcessExpectSuccesExitCode("Main"); Succes -> Success typo. *Everywhere* test/jdk/java/lang/annotation/LoaderLeakTest.java line 133: > 131: class SimpleClassLoader extends ClassLoader { > 132: > 133: private Hashtable classes = new Hashtable(); A good upgrade would be to use HashMap instead of the ancient HashTable. Also, avoid Raw types and cleanup other compile time warnings. ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From bchristi at openjdk.java.net Thu Dec 3 22:05:55 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 3 Dec 2020 22:05:55 GMT Subject: RFR: 8235784: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java fails due to timeout with fastdebug bits In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 19:10:46 GMT, Mandy Chung wrote: > VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build and slow mac os machines. I can't reproduce this locally. It fails on jdk 16 internal testing on a few builds. I propose to increase the timeout and see if that is adequate or not. We will re-examine this test if the increased timeout is not adequate. Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1603 From naoto at openjdk.java.net Thu Dec 3 22:05:55 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Dec 2020 22:05:55 GMT Subject: RFR: 8235784: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java fails due to timeout with fastdebug bits In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 19:10:46 GMT, Mandy Chung wrote: > VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build and slow mac os machines. I can't reproduce this locally. It fails on jdk 16 internal testing on a few builds. I propose to increase the timeout and see if that is adequate or not. We will re-examine this test if the increased timeout is not adequate. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1603 From mchung at openjdk.java.net Thu Dec 3 22:17:55 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 22:17:55 GMT Subject: Integrated: 8235784: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java fails due to timeout with fastdebug bits In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 19:10:46 GMT, Mandy Chung wrote: > VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build and slow mac os machines. I can't reproduce this locally. It fails on jdk 16 internal testing on a few builds. I propose to increase the timeout and see if that is adequate or not. We will re-examine this test if the increased timeout is not adequate. This pull request has now been integrated. Changeset: f0b11940 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/f0b11940 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod 8235784: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java fails due to timeout with fastdebug bits Reviewed-by: bchristi, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/1603 From isipka at openjdk.java.net Thu Dec 3 22:54:13 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 3 Dec 2020 22:54:13 GMT Subject: RFR: 8256894: define test groups [v3] In-Reply-To: References: Message-ID: > Defined new test groups as defined in ticket. @fguallini Ivan ?ipka has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8257516: define test group for manual tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1416/files - new: https://git.openjdk.java.net/jdk/pull/1416/files/c91558be..c47bb096 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1416&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1416&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1416/head:pull/1416 PR: https://git.openjdk.java.net/jdk/pull/1416 From mchung at openjdk.java.net Thu Dec 3 23:00:03 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Dec 2020 23:00:03 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` Message-ID: This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - 8256167: Convert JDK use of to - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - minor cleanup - Merge branch 'refersto' of https://github.com/kimbarrett/openjdk-jdk into refersTo - improve refersTo0 descriptions - basic functional test - change referent access - expand test - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f0b11940...b1e645b1 Changes: https://git.openjdk.java.net/jdk/pull/1609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256167 Stats: 52 lines in 12 files changed: 7 ins; 10 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1609/head:pull/1609 PR: https://git.openjdk.java.net/jdk/pull/1609 From isipka at openjdk.java.net Thu Dec 3 23:23:56 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 3 Dec 2020 23:23:56 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: On Thu, 3 Dec 2020 19:37:11 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java > Please rename the class Seppuku to a more generic name for a process that exits as the result of an uncaught exception. Perhaps a simple "UncaughtExit". How does `UncaughtExitSimulator` sound? test/jdk/java/lang/Thread/UncaughtExceptionsTest.java line 94: > 92: final static String EXPECTED_RESULT = "OK"; > 93: > 94: public static void seppuku() { throw new RuntimeException("Seppuku!"); } @RogerRiggs I suggest method name instead of `seppuku` to be `throwRuntimeException`? And to remove the message from the exception constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/1578 From rriggs at openjdk.java.net Thu Dec 3 23:40:56 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 3 Dec 2020 23:40:56 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: On Thu, 3 Dec 2020 23:07:25 GMT, Ivan ?ipka wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8166026: Refactor java/lang shell tests to java > > test/jdk/java/lang/Thread/UncaughtExceptionsTest.java line 94: > >> 92: final static String EXPECTED_RESULT = "OK"; >> 93: >> 94: public static void seppuku() { throw new RuntimeException("Seppuku!"); } > > @RogerRiggs I suggest method name instead of `seppuku` to be `throwRuntimeException`? > And to remove the message from the exception constructor. Both suggestions work for me. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1578 From joehw at openjdk.java.net Fri Dec 4 01:20:55 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 4 Dec 2020 01:20:55 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: <-jIYkKiV85dsQqhGn6weNE_XT9LgzYW3dEjhCSU22a8=.1d03b851-5d9d-42eb-aabe-90bfc9412d19@github.com> On Thu, 3 Dec 2020 14:44:05 GMT, Marius Volkhart wrote: >> @MariusVolkhart Here is a PR for your branch so the test works with jtreg: >> https://github.com/MariusVolkhart/jdk/pull/1 >> >> Fails before the JDK patch and passes after. >> >> Run it with: >> $ rm -rf JTwork JTreport && jtreg -jdk:./build/linux-x86_64-server-release/images/jdk -verbose:summary test/jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java >> Passed: javax/xml/jaxp/8256515/XmlInputFactoryTest.java >> Test results: passed: 1 >> Results are in *.jtr files: >> >> $ find JTwork/ -name *.jtr >> JTwork/javax/xml/jaxp/8256515/XmlInputFactoryTest.jtr >> >> Or using the test framework of OpenJDK with: >> >> $ bash configure --with-jtreg=/path/to/jtreg [...] >> $ make test TEST="jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java" >> >> HTH > > @jerboaa Thanks! That PR was immensely helpful, not just in helping get this change moving, but in helping me understand how to write the tests for next time! When you update, pls do a merge from the latest upstream jdk master. The changeset is pretty far behind the master. ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From sspitsyn at openjdk.java.net Fri Dec 4 03:10:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 4 Dec 2020 03:10:57 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Hi Mandy, Looks good. I guess, you are going to update the copyright comments before the push. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From smarks at openjdk.java.net Fri Dec 4 06:57:07 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Dec 2020 06:57:07 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message Message-ID: This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. Separately, I'll work on retrofitting various call sites around the JDK to use this method. ------------- Commit messages: - 8247373: ArraysSupport.newLength doc, test, and exception message Changes: https://git.openjdk.java.net/jdk/pull/1617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247373 Stats: 171 lines in 4 files changed: 137 ins; 3 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1617/head:pull/1617 PR: https://git.openjdk.java.net/jdk/pull/1617 From stuart.marks at oracle.com Fri Dec 4 06:58:50 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 3 Dec 2020 22:58:50 -0800 Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: Hi Martin, I'd appreciate it if you could take a look at this. Thanks, s'marks On 12/3/20 10:57 PM, Stuart Marks wrote: > This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: > > 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! > > 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. > > Separately, I'll work on retrofitting various call sites around the JDK to use this method. > > ------------- > > Commit messages: > - 8247373: ArraysSupport.newLength doc, test, and exception message > > Changes: https://git.openjdk.java.net/jdk/pull/1617/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8247373 > Stats: 171 lines in 4 files changed: 137 ins; 3 del; 31 mod > Patch: https://git.openjdk.java.net/jdk/pull/1617.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1617/head:pull/1617 > > PR: https://git.openjdk.java.net/jdk/pull/1617 > From alanb at openjdk.java.net Fri Dec 4 09:02:54 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 09:02:54 GMT Subject: Integrated: 8255542: Attribute length of Module, ModulePackages and other attributes is ignored In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 10:58:43 GMT, Alan Bateman wrote: > The attribute_length of known ModuleXXXX attributes in the module-info.class is currently ignored. It should be checked and the class rejected if the attribute length doesn't exactly match the length of the info in the attribute. > > There are several ways to fix this. I initially limited the reading of the attribute_info to the attribute length but this resulted in confusing exception messages as the attribute appears truncated. The exception messages are clearer when it checks that the attribute length corresponds to the number of bytes read. This pull request has now been integrated. Changeset: 2b4a423f Author: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/2b4a423f Stats: 567 lines in 8 files changed: 562 ins; 1 del; 4 mod 8255542: Attribute length of Module, ModulePackages and other attributes is ignored Reviewed-by: mchung, dfuchs, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1407 From shade at openjdk.java.net Fri Dec 4 09:25:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 09:25:00 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Replacements look fine to me. src/java.base/share/classes/java/util/WeakHashMap.java line 291: > 289: if (e.refersTo(key)) return true; > 290: > 291: // then checks for equality Obnoxiously minor nit: plurality is inconsistent. `check if the given entry...` above, and `then check[s] for equality`. Should be `...then check for equality`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From chegar at openjdk.java.net Fri Dec 4 10:05:44 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 4 Dec 2020 10:05:44 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 16:33:15 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add class level clarification of use of uppercase for primitive conversions > Switched order of declaration of a couple of method to make the javadoc sequence easier to read Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From dfuchs at openjdk.java.net Fri Dec 4 10:05:48 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Dec 2020 10:05:48 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 16:33:15 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add class level clarification of use of uppercase for primitive conversions > Switched order of declaration of a couple of method to make the javadoc sequence easier to read Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From ihse at openjdk.java.net Fri Dec 4 10:28:30 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 10:28:30 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module Message-ID: 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 From ihse at openjdk.java.net Fri Dec 4 10:32:11 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 10:32:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > 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. To facilitate review, here is a list on how the different directories under make/data has moved. **To java.base:** * blacklistedcertsconverter * cacerts * characterdata * charsetmapping * cldr * currency * lsrdata * publicsuffixlist * tzdata * unicodedata **To java.desktop:** * dtdbuilder * fontconfig * macosxicons * x11wrappergen **To jdk.compiler:** * symbols **To jdk.jdi:** * jdwp **Remaining in make:** * bundle * docs-resources * macosxsigning * mainmanifest ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From dfuchs at openjdk.java.net Fri Dec 4 10:41:12 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Dec 2020 10:41:12 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Hi Mandy, This looks good to me. There are a few places where a single call to `Reference::get` is replaced by multiple calls to `Reference::refersTo`, allowing the reference to get cleared in between, but as far as I could see that doesn't affect the overall logic which is still sound. So LGTM! best regards, -- daniel ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From mcimadamore at openjdk.java.net Fri Dec 4 11:07:31 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Dec 2020 11:07:31 GMT Subject: RFR: 8257622: MemoryAccess methods are missing @ForceInline annotations [v2] In-Reply-To: References: Message-ID: > The accessor methods in the `MemoryAccess` class are missing `@ForceInline` annotations. This causes odd behavior on certain benchmarks, especially if these methods are called many times in the body of a single method. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix extra whitespace in benchmark ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1570/files - new: https://git.openjdk.java.net/jdk/pull/1570/files/b2965389..737af864 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1570&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1570&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1570/head:pull/1570 PR: https://git.openjdk.java.net/jdk/pull/1570 From alanb at openjdk.java.net Fri Dec 4 11:17:12 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 11:17:12 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie wrote: >> 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. > > To facilitate review, here is a list on how the different directories under make/data has moved. > > **To java.base:** > * blacklistedcertsconverter > * cacerts > * characterdata > * charsetmapping > * cldr > * currency > * lsrdata > * publicsuffixlist > * tzdata > * unicodedata > > **To java.desktop:** > * dtdbuilder > * fontconfig > * macosxicons > * x11wrappergen > > **To jdk.compiler:** > * symbols > > **To jdk.jdi:** > * jdwp > > **Remaining in make:** > * bundle > * docs-resources > * macosxsigning > * mainmanifest Are you proposing any text or guidelines to be added to JEP 201 as part of this? I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From alanb at openjdk.java.net Fri Dec 4 11:23:14 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 11:23:14 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: <_AwUb5GoPBZ7J4zM9wbX6uojd8dXt14z22gyHCS-P-g=.2087d23c-a808-4ba1-819d-9dd843f21427@github.com> On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Good to use this done in the same release as refersTo was added. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1609 From ihse at openjdk.java.net Fri Dec 4 11:42:15 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 11:42:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote: >> To facilitate review, here is a list on how the different directories under make/data has moved. >> >> **To java.base:** >> * blacklistedcertsconverter >> * cacerts >> * characterdata >> * charsetmapping >> * cldr >> * currency >> * lsrdata >> * publicsuffixlist >> * tzdata >> * unicodedata >> >> **To java.desktop:** >> * dtdbuilder >> * fontconfig >> * macosxicons >> * x11wrappergen >> >> **To jdk.compiler:** >> * symbols >> >> **To jdk.jdi:** >> * jdwp >> >> **Remaining in make:** >> * bundle >> * docs-resources >> * macosxsigning >> * mainmanifest > > Are you proposing any text or guidelines to be added to JEP 201 as part of this? > > I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written. I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Fri Dec 4 11:42:15 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 11:42:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote: >> Are you proposing any text or guidelines to be added to JEP 201 as part of this? >> >> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. > > @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written. > > I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented. And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Fri Dec 4 11:49:16 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Dec 2020 11:49:16 GMT Subject: Integrated: 8257622: MemoryAccess methods are missing @ForceInline annotations In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:47:10 GMT, Maurizio Cimadamore wrote: > The accessor methods in the `MemoryAccess` class are missing `@ForceInline` annotations. This causes odd behavior on certain benchmarks, especially if these methods are called many times in the body of a single method. This pull request has now been integrated. Changeset: dede01eb Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/dede01eb Stats: 325 lines in 3 files changed: 325 ins; 0 del; 0 mod 8257622: MemoryAccess methods are missing @ForceInline annotations Reviewed-by: jvernee, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1570 From alanb at openjdk.java.net Fri Dec 4 12:33:15 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 12:33:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie wrote: > And I can certainly move jdwp.spec to java.base instead. If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Fri Dec 4 13:12:27 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Dec 2020 13:12:27 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v5] In-Reply-To: References: Message-ID: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Cleanup as suggested on the review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1483/files - new: https://git.openjdk.java.net/jdk/pull/1483/files/537e267f..09e0c186 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=03-04 Stats: 187 lines in 7 files changed: 38 ins; 114 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483 PR: https://git.openjdk.java.net/jdk/pull/1483 From alanb at openjdk.java.net Fri Dec 4 13:29:18 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Dec 2020 13:29:18 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v5] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 13:12:27 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/lang/Class.java line 3043: > 3041: for (Class c : subClasses) { > 3042: if (Proxy.isProxyClass(c)) > 3043: throw new InternalError("a permitted subclass should not be a proxy class: " + c); Minor nit but I think the indentation may be messed up here. src/java.base/share/classes/java/lang/Class.java line 4394: > 4392: * implement this class or interface if it is sealed. The order of such elements > 4393: * is unspecified. If this {@code Class} object represents a primitive type, > 4394: * {@code void}, an array type, or a class or interface that is not sealed, Did you mean {@code Void} here? src/java.base/share/classes/java/lang/Class.java line 4403: > 4401: * loader} of the current {@code Class} object). > 4402: * The {@code Class} objects which can be obtained using this procedure, > 4403: * and which are direct subinterfaces or subclasses of this class or interface, Minor suggestion is to drop "using this procedure" from this sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From github.com+1709517+mariusvolkhart at openjdk.java.net Fri Dec 4 13:30:25 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Fri, 4 Dec 2020 13:30:25 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v2] In-Reply-To: References: Message-ID: > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. Marius Volkhart has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Adjust test so it works with jtreg - Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. - Add test for XmlInputFactory ------------- Changes: https://git.openjdk.java.net/jdk/pull/1056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1056&range=01 Stats: 47 lines in 2 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1056/head:pull/1056 PR: https://git.openjdk.java.net/jdk/pull/1056 From erikj at openjdk.java.net Fri Dec 4 14:08:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Dec 2020 14:08:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >> And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it. > >> And I can certainly move jdwp.spec to java.base instead. > > If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol. My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From erikj at openjdk.java.net Fri Dec 4 14:08:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Dec 2020 14:08:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson wrote: >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs. Regarding the chosen layout. Did you consider following the existing pattern of src//{share,}/data? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Fri Dec 4 15:10:12 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Dec 2020 15:10:12 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v5] In-Reply-To: References: Message-ID: <7mxDajR7S_ajQQLny222__jY2QXcUbKksdcK67jjir4=.fa29bd7f-24f3-4e3f-8aea-3979699ba3a5@github.com> On Fri, 4 Dec 2020 13:12:27 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Compiler changes look good to me ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1483 From ihse at openjdk.java.net Fri Dec 4 15:20:14 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Dec 2020 15:20:14 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote: >> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs. > > Regarding the chosen layout. Did you consider following the existing pattern of src//{share,}/data? @erikj79 Good point, that makes much more sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From prappo at openjdk.java.net Fri Dec 4 15:38:11 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 4 Dec 2020 15:38:11 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: <_xofj9Juf4O7Mgi0GTuK81yn_91FD0d2g3Fe6eExBXg=.39a225aa-201d-46e7-8b08-cc6657574f87@github.com> References: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com> <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> <_xofj9Juf4O7Mgi0GTuK81yn_91FD0d2g3Fe6eExBXg=.39a225aa-201d-46e7-8b08-cc6657574f87@github.com> Message-ID: On Mon, 30 Nov 2020 15:08:51 GMT, Pavel Rappo wrote: >> @johnlinp, thanks for updating the CSR draft; it is much better now. >> >> @stuart-marks, I think we could further improve this snippet. This `if` statement seems to use an optimization: >> >> if (oldValue != null || map.containsKey(key)) >> >> I don't think we should include an optimization into the specification unless that optimization also improves readability. Is this the case here? Could this be better? >> >> if (map.containsKey(key)) > > I would even go as far as to rewrite that snippet like this: > > if (newValue == null) { > remove(key); > } else { > put(key, newValue); > } > return newValue; > > This rewrite is possible thanks to the following properties of `Map.remove(Object key)`: > > 1. A call with an unmapped `key` has no effect. > 2. A call with a mapped `key` has the same semantics regardless of the value that this key is mapped to. > > In particular, (2) covers `null` values. > > To me, this rewrite reads better; however, I understand that readability is subjective and that snippets used in `@implSpec` might be subject to additional requirements. > @pavelrappo The intended effect of the revised snippet is sensible, but again I note that it differs from the actual default implementation. Specifically: if the map does not contain the key and newValue is null, the default implementation currently does nothing, whereas the revised snippet calls `remove(key)`. This should have no effect _on the map_ but a subclass might override `remove` and this behavior difference is observable. (The typical example of this is maintaining a counter of the number of operations. I think _Effective Java_ uses that example in discussing subclassing.) I think the main priority here is fidelity to what the default implementation actually does -- at least, concerning operations on _this_ -- and less on readability. Although we should really have a conversation on code snippets in API specifications, this thread is not the place for that. However, I will minimally comment on some of what you've just said. 1. If a high-fidelity copy is not enough, an identical copy is required; that suggests a JavaDoc facility for embedding portions of code into doc comments. 2. I have to note that `Map.merge` (a method whose semantics is very close to that of `Map.compute`) is specified and implemented very similarly to what my [comment #1](https://github.com/openjdk/jdk/pull/714#issuecomment-735843488) proposed. > The current snippet proposed by @johnlinp does seem to have the same behavior as the default implementation; I would avoid trying to "optimize" this. However, it does express the conditions and return value somewhat differently from the way the default implementation does. I think those differences are not significant to subclasses and are mostly stylistic. The original `@implSpec` snippet attempted to handle the cases separately, whereas the current proposed snippet minimizes them (while still agreeing with the implementation's behavior). I'm not too concerned about this. I think the current snippet is acceptable. Again, the main priority is agreement with the implementation. Perhaps there's some confusion. If anything my [comment #2](https://github.com/openjdk/jdk/pull/714#issuecomment-735798573) was proposing to _remove_ an optimization carried over from the default implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From rriggs at openjdk.java.net Fri Dec 4 16:05:15 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Dec 2020 16:05:15 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 06:50:14 GMT, Stuart Marks wrote: > This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: > > 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! > > 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. > > Separately, I'll work on retrofitting various call sites around the JDK to use this method. Nice clean description of the algorithm. src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 654: > 652: return SOFT_MAX_ARRAY_LENGTH; > 653: } else { > 654: return minLength; Isn't this last `else if... then.. else` the same as: `return Math.max(minLength, SOFT_MAX_ARRAY_LENGTH)` src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 640: > 638: int prefLength = oldLength + Math.max(minGrowth, prefGrowth); // might overflow > 639: if (0 < prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { > 640: return prefLength; In spite of the assert `minGrowth > 0`, that is unchecked, I would suggest prefLength == 0 to return prefLength. ```if (0 <= prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { return prefLength;``` Otherwise, it falls into hughLength(...) which will return the SOFT_MAX_ARRAY_LENGTH. It would be more robust if the algorithm was well defined if either min or pref were zero. test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 70: > 68: { IMAX-2, 1, IMAX, IMAX-1 }, > 69: { IMAX-1, 1, IMAX, IMAX } > 70: }; Adding test cases for zero (0) for the min and preferred would be good to include and show any unpredictable behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From jlahoda at openjdk.java.net Fri Dec 4 16:22:28 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Dec 2020 16:22:28 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v6] In-Reply-To: References: Message-ID: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Cleanup as suggested on the review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1483/files - new: https://git.openjdk.java.net/jdk/pull/1483/files/09e0c186..b5304057 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483 PR: https://git.openjdk.java.net/jdk/pull/1483 From jlahoda at openjdk.java.net Fri Dec 4 16:25:15 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Dec 2020 16:25:15 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v5] In-Reply-To: References: Message-ID: <-NIy_0DQvgBZJOTV-nOL86tfgrG8nDsDwG1JUHFxJcQ=.928907ab-f273-4ab5-aaf8-645f32bb3da4@github.com> On Fri, 4 Dec 2020 13:25:04 GMT, Alan Bateman wrote: >> Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/java.base/share/classes/java/lang/Class.java line 4394: > >> 4392: * implement this class or interface if it is sealed. The order of such elements >> 4393: * is unspecified. If this {@code Class} object represents a primitive type, >> 4394: * {@code void}, an array type, or a class or interface that is not sealed, > > Did you mean {@code Void} here? I think this means `void.class`. `void.class` is a little special (as are the Class objects for primitive types, like `int.class`), but Void.class or Integer.class are not so much special. I've updated the patch based on the other comments - thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From chegar at openjdk.java.net Fri Dec 4 16:37:16 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 4 Dec 2020 16:37:16 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v6] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:22:28 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup as suggested on the review. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From prappo at openjdk.java.net Fri Dec 4 16:57:13 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 4 Dec 2020 16:57:13 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> References: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com> <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> Message-ID: <6YnbHWJyV8oH3c2NfuqMmCN6VpiCCrAC37sQQJh6uK0=.19c44986-5b49-4fab-adda-05fe83c69629@github.com> On Sat, 28 Nov 2020 08:42:52 GMT, John Lin wrote: >> @johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this: >> returning the current value or {@code null} if absent:``` > > @pavelrappo Please see my updated CSR below. Thanks. > > # Map::compute should have the implementation requirement match its default implementation > > ## Summary > > The implementation requirement of Map::compute does not match its default implementation. Besides, it has some other minor issues. We should fix it. > > ## Problem > > The documentation of the implementation requirements for Map::compute has the following problems: > 1. It doesn't match its default implementation. > 1. It lacks of the return statements for most of the if-else cases. > 1. The indents are 3 spaces, while the convention is 4 spaces. > 1. The if-else is overly complicated and can be simplified. > 1. The surrounding prose contains incorrect statements. > > ## Solution > > Rewrite the documentation of Map::compute to match its default implementation and solve the above mentioned problems. > > ## Specification > > diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java > index b1de34b42a5..b30e3979259 100644 > --- a/src/java.base/share/classes/java/util/Map.java > +++ b/src/java.base/share/classes/java/util/Map.java > @@ -1107,23 +1107,17 @@ public interface Map { > * > * @implSpec > * The default implementation is equivalent to performing the following > - * steps for this {@code map}, then returning the current value or > - * {@code null} if absent: > + * steps for this {@code map}: > * > * 

 {@code
>       * V oldValue = map.get(key);
>       * V newValue = remappingFunction.apply(key, oldValue);
> -     * if (oldValue != null) {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       map.remove(key);
> -     * } else {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       return null;
> +     * if (newValue != null) {
> +     *     map.put(key, newValue);
> +     * } else if (oldValue != null || map.containsKey(key)) {
> +     *     map.remove(key);
>       * }
> +     * return newValue;
>       * }
> * > *

The default implementation makes no guarantees about detecting if the 1. @johnlinp I've created the CSR: https://bugs.openjdk.java.net/browse/JDK-8257768 2. @dfuch, @stuart-marks, and I-cannot-seem-to-find-Martin-Buchholz's-GitHub-username: care to review that CSR? ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From bpb at openjdk.java.net Fri Dec 4 17:03:20 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 4 Dec 2020 17:03:20 GMT Subject: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final Message-ID: Please review this trivial change to make the `writeBuffer` array field final and move it to the beginning of the class where other fields are declared. ------------- Commit messages: - 8257750: writeBuffer field of java.io.DataOutputStream should be final Changes: https://git.openjdk.java.net/jdk/pull/1627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257750 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1627/head:pull/1627 PR: https://git.openjdk.java.net/jdk/pull/1627 From lancea at openjdk.java.net Fri Dec 4 17:17:12 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Dec 2020 17:17:12 GMT Subject: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:58:56 GMT, Brian Burkhalter wrote: > Please review this trivial change to make the `writeBuffer` array field final and move it to the beginning of the class where other fields are declared. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1627 From naoto at openjdk.java.net Fri Dec 4 17:17:13 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Dec 2020 17:17:13 GMT Subject: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:58:56 GMT, Brian Burkhalter wrote: > Please review this trivial change to make the `writeBuffer` array field final and move it to the beginning of the class where other fields are declared. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1627 From bpb at openjdk.java.net Fri Dec 4 17:22:29 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 4 Dec 2020 17:22:29 GMT Subject: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final [v2] In-Reply-To: References: Message-ID: > Please review this trivial change to make the `writeBuffer` array field final and move it to the beginning of the class where other fields are declared. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8257750: Change "byte writeBuffer[]" to "byte[] writeBuffer" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1627/files - new: https://git.openjdk.java.net/jdk/pull/1627/files/c994c07c..0ddd1068 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1627&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1627&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1627/head:pull/1627 PR: https://git.openjdk.java.net/jdk/pull/1627 From lancea at openjdk.java.net Fri Dec 4 17:30:14 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Dec 2020 17:30:14 GMT Subject: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final [v2] In-Reply-To: References: Message-ID: <1SNPa8CPo-6osWnmAW4nYk9qzh3j9jJ_cLYhDtsEwXY=.829be8ba-e5b6-45d2-909f-de4e878cebb4@github.com> On Fri, 4 Dec 2020 17:22:29 GMT, Brian Burkhalter wrote: >> Please review this trivial change to make the `writeBuffer` array field final and move it to the beginning of the class where other fields are declared. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8257750: Change "byte writeBuffer[]" to "byte[] writeBuffer" Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1627 From smarks at openjdk.java.net Fri Dec 4 17:34:12 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Dec 2020 17:34:12 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 15:47:51 GMT, Roger Riggs wrote: >> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: >> >> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! >> >> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. >> >> Separately, I'll work on retrofitting various call sites around the JDK to use this method. > > src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 654: > >> 652: return SOFT_MAX_ARRAY_LENGTH; >> 653: } else { >> 654: return minLength; > > Isn't this last `else if... then.. else` the same as: > `return Math.max(minLength, SOFT_MAX_ARRAY_LENGTH)` It is, and I considered replacing it, but I felt that it obscured what was going on. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From smarks at openjdk.java.net Fri Dec 4 17:54:16 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Dec 2020 17:54:16 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 15:53:01 GMT, Roger Riggs wrote: >> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: >> >> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! >> >> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. >> >> Separately, I'll work on retrofitting various call sites around the JDK to use this method. > > src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 640: > >> 638: int prefLength = oldLength + Math.max(minGrowth, prefGrowth); // might overflow >> 639: if (0 < prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { >> 640: return prefLength; > > In spite of the assert `minGrowth > 0`, that is unchecked, I would suggest prefLength == 0 to return prefLength. > ```if (0 <= prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { > return prefLength;``` > Otherwise, it falls into hughLength(...) which will return the SOFT_MAX_ARRAY_LENGTH. > > It would be more robust if the algorithm was well defined if either min or pref were zero. The preconditions aren't checked, because this is an internal method, and the code size is minimized in order to help inlining. That's also why `hugeLength` is a separate method. (I guess I could add comments to this effect.) With this in mind it's hard to reason about robustness. If prefLength is zero, this can only be because some precondition was violated (e.g., oldLength is negative). If this were to occur there doesn't seem to be any advantage choosing one undefined behavior over another. > test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 70: > >> 68: { IMAX-2, 1, IMAX, IMAX-1 }, >> 69: { IMAX-1, 1, IMAX, IMAX } >> 70: }; > > Adding test cases for zero (0) for the min and preferred would be good to include and show any unpredictable behavior. No, I don't want to add test cases that violate the preconditions. I guess I could add a prefGrowth==0 case though. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From mchung at openjdk.java.net Fri Dec 4 18:00:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 18:00:16 GMT Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v6] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:22:28 GMT, Jan Lahoda wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this iteration we are: >>> >>> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >>> >>> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >>> >>> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >>> >>> * adding code to make sure that annotations can't be sealed >>> >>> * improving some tests >>> >>> >>> TIA >>> >>> Related specs: >>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) >> >> This PR strives to reflect the review comments from 1227: >> * adjustments to javadoc of j.l.Class methods >> * package access checks in Class.getPermittedSubclasses() >> * fixed to the narrowing conversion/castability as pointed out by Maurizio > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup as suggested on the review. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From mchung at openjdk.java.net Fri Dec 4 18:12:17 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 18:12:17 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: <2VSYwnm42o5BZfPO2S9uk88siPje_jMx25x03t_xQuc=.a78bc191-7df4-4386-a3ac-4a118518def4@github.com> On Fri, 4 Dec 2020 09:19:23 GMT, Aleksey Shipilev wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.base/share/classes/java/util/WeakHashMap.java line 291: > >> 289: if (e.refersTo(key)) return true; >> 290: >> 291: // then checks for equality > > Obnoxiously minor nit: plurality is inconsistent. `check if the given entry...` above, and `then check[s] for equality`. Should be `...then check for equality`? OK. Fixed this grammatical nit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From kbarrett at openjdk.java.net Fri Dec 4 18:18:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 4 Dec 2020 18:18:13 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. src/java.base/share/classes/java/util/WeakHashMap.java line 293: > 291: // then checks for equality > 292: Object k = e.get(); > 293: return key == k || key.equals(k); I think `key == k` is already covered by refersTo. But k could be null; checking for that here might be useful, to skip the call to equals in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From github.com+18482851+stefan-zobel at openjdk.java.net Fri Dec 4 18:20:18 2020 From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel) Date: Fri, 4 Dec 2020 18:20:18 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 06:50:14 GMT, Stuart Marks wrote: > This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: > > 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! > > 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. > > Separately, I'll work on retrofitting various call sites around the JDK to use this method. src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 626: > 624: * attempt an array allocation with that length and encounter an OutOfMemoryError. > 625: * Of course, regardless of the length value returned from this method, the caller > 626: * may encounter OutOfMemoryError if there is insufficient heap to fufill the request. typo in line 626: fufill -> fulfill ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From bchristi at openjdk.java.net Fri Dec 4 18:31:23 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 4 Dec 2020 18:31:23 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected Message-ID: Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). The new version of the test passes 100 times out of 100 on the test farm. ------------- Commit messages: - Add gcAwait() mechanism Changes: https://git.openjdk.java.net/jdk/pull/1630/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1630&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8200102 Stats: 52 lines in 1 file changed: 41 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1630/head:pull/1630 PR: https://git.openjdk.java.net/jdk/pull/1630 From martin at openjdk.java.net Fri Dec 4 18:36:15 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Fri, 4 Dec 2020 18:36:15 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: <6YnbHWJyV8oH3c2NfuqMmCN6VpiCCrAC37sQQJh6uK0=.19c44986-5b49-4fab-adda-05fe83c69629@github.com> References: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com> <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com> <6YnbHWJyV8oH3c2NfuqMmCN6VpiCCrAC37sQQJh6uK0=.19c44986-5b49-4fab-adda-05fe83c69629@github.com> Message-ID: On Fri, 4 Dec 2020 16:54:26 GMT, Pavel Rappo wrote: >> @pavelrappo Please see my updated CSR below. Thanks. >> >> # Map::compute should have the implementation requirement match its default implementation >> >> ## Summary >> >> The implementation requirement of Map::compute does not match its default implementation. Besides, it has some other minor issues. We should fix it. >> >> ## Problem >> >> The documentation of the implementation requirements for Map::compute has the following problems: >> 1. It doesn't match its default implementation. >> 1. It lacks of the return statements for most of the if-else cases. >> 1. The indents are 3 spaces, while the convention is 4 spaces. >> 1. The if-else is overly complicated and can be simplified. >> 1. The surrounding prose contains incorrect statements. >> >> ## Solution >> >> Rewrite the documentation of Map::compute to match its default implementation and solve the above mentioned problems. >> >> ## Specification >> >> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java >> index b1de34b42a5..b30e3979259 100644 >> --- a/src/java.base/share/classes/java/util/Map.java >> +++ b/src/java.base/share/classes/java/util/Map.java >> @@ -1107,23 +1107,17 @@ public interface Map { >> * >> * @implSpec >> * The default implementation is equivalent to performing the following >> - * steps for this {@code map}, then returning the current value or >> - * {@code null} if absent: >> + * steps for this {@code map}: >> * >> * 

 {@code
>>       * V oldValue = map.get(key);
>>       * V newValue = remappingFunction.apply(key, oldValue);
>> -     * if (oldValue != null) {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       map.remove(key);
>> -     * } else {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       return null;
>> +     * if (newValue != null) {
>> +     *     map.put(key, newValue);
>> +     * } else if (oldValue != null || map.containsKey(key)) {
>> +     *     map.remove(key);
>>       * }
>> +     * return newValue;
>>       * }
>> * >> *

The default implementation makes no guarantees about detecting if the > > 1. @johnlinp I've created the CSR: https://bugs.openjdk.java.net/browse/JDK-8257768 > 2. @dfuch, @stuart-marks, and I-cannot-seem-to-find-Martin-Buchholz's-GitHub-username: care to review that CSR? Hello github - this is my first ever comment. The javadoc specs for the various compute methods in all the Map classes should be maintained consistently and holistically. Sorry for not having done so years ago. Pavel is thinking about code snippets for all of OpenJDK today, while I have been thinking about code snippets in jsr166. jsr166 code snippets have a consistent style that should also be used for Map.java, but we've had a mild case of maintainer style divergence. ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From stuart.marks at oracle.com Fri Dec 4 18:53:45 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Dec 2020 10:53:45 -0800 Subject: MatchResult support for named groups In-Reply-To: References: <14517.1606845585151306433@groups.io> Message-ID: Hi Cay, Thanks for mentioning this. It's good to know that adding this provides value to people who are actually trying to use this stuff (as opposed to adding stuff merely for the sake of completeness, as often seems to arise). I've added some notes to JDK-8065554. Looking at this more closely, it seems to me that MatchResult ought to include more match-result-related information that's currently only in Matcher, namely: 1. whether there was a match at all 2. hitEnd 3. requireEnd If you have any thoughts on these, please let me know. s'marks On 12/2/20 2:53 AM, Cay Horstmann wrote: > Hello, I'd like to raise awareness for > > https://bugs.openjdk.java.net/browse/JDK-8180352 > https://bugs.openjdk.java.net/browse/JDK-8072984 > https://bugs.openjdk.java.net/browse/JDK-8065554 > > These all ask for MatchResult.group(String name). What they don't mention is that > this is more urgent in light of the methods > > Stream Matcher.results() // > https://bugs.openjdk.java.net/browse/JDK-8071479 > Stream Scanner.findAll(Pattern pattern) // > https://bugs.openjdk.java.net/browse/JDK-8072722 > > In particular, Matcher.results() seems a cleaner way of collecting match results > than calling while (matcher.find()). > > But then MatchResult needs to support the same queries that Matcher provides. I > believe the only missing one is group(String name). > > Cheers, > > Cay > > NB. There are related requests that ask for finding group names in patterns, or for > correlating group names and numbers. I have formed no opinion on their merits. > From rriggs at openjdk.java.net Fri Dec 4 19:17:14 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Dec 2020 19:17:14 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 17:49:25 GMT, Stuart Marks wrote: >> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 640: >> >>> 638: int prefLength = oldLength + Math.max(minGrowth, prefGrowth); // might overflow >>> 639: if (0 < prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { >>> 640: return prefLength; >> >> In spite of the assert `minGrowth > 0`, that is unchecked, I would suggest prefLength == 0 to return prefLength. >> ```if (0 <= prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { >> return prefLength;``` >> Otherwise, it falls into hughLength(...) which will return the SOFT_MAX_ARRAY_LENGTH. >> >> It would be more robust if the algorithm was well defined if either min or pref were zero. > > The preconditions aren't checked, because this is an internal method, and the code size is minimized in order to help inlining. That's also why `hugeLength` is a separate method. (I guess I could add comments to this effect.) With this in mind it's hard to reason about robustness. If prefLength is zero, this can only be because some precondition was violated (e.g., oldLength is negative). If this were to occur there doesn't seem to be any advantage choosing one undefined behavior over another. Is there a reason the code would not naturally work when either min or preferred is zero? Why are their preconditions? What do they allow? These methods are used in enough places that a slip in any of the clients would be trouble and hard to track down. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From plevart at openjdk.java.net Fri Dec 4 19:50:15 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Dec 2020 19:50:15 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java line 127: > 125: T got = get(); > 126: return got != null && wr.refersTo(got); > 127: } Here you could pre-screen the get() with: if (this.refersTo(null) != wr.refersTo(null)) return false; In case one of the two WeakReference(s) is cleared and the other is not, they are not equal and you don't call this.get() in such case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From github.com+34924738+mahendrachhipa at openjdk.java.net Fri Dec 4 19:50:24 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Fri, 4 Dec 2020 19:50:24 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer Message-ID: jaxp.library.SimpleHttpServer https://bugs.openjdk.java.net/browse/JDK-8212035 ------------- Commit messages: - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with Changes: https://git.openjdk.java.net/jdk/pull/1632/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212035 Stats: 276 lines in 16 files changed: 72 ins; 141 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/1632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632 PR: https://git.openjdk.java.net/jdk/pull/1632 From mchung at openjdk.java.net Fri Dec 4 19:54:11 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 19:54:11 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:23:55 GMT, Brent Christian wrote: > Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. > > The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). > > The new version of the test passes 100 times out of 100 on the test farm. Alternatively, you can simply use `test/libjdk/test/lib/util/ForceGC` in the testlibrary. ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From darcy at openjdk.java.net Fri Dec 4 19:58:13 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Dec 2020 19:58:13 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 10:00:21 GMT, Chris Hegarty wrote: >> Update Class::isRecord to only return true for classes that are final. >> >> The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. >> >> Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: >> >> 1. It is a compile-time error if a record declaration has the modifier abstract. >> 2. A record declaration is implicitly final. >> 3. The direct superclass type of a record class is Record. >> >> Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > fix issue in ByteCodeLoader Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1543 From kcr at openjdk.java.net Fri Dec 4 20:08:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Dec 2020 20:08:16 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. You have a typo that will cause a compilation error. src/java.base/share/classes/java/util/WeakHashMap.java line 437: > 435: int index = indexFor(h, tab.length); > 436: Entry e = tab[index]; > 437: while (e != null && !(e.hash == h && matchesKey(e, k)) This doesn't compile, which is why the checks from the GitHub actions build failed. ------------- Changes requested by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/1609 From mchung at openjdk.java.net Fri Dec 4 20:12:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 20:12:13 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:12:36 GMT, Kim Barrett wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.base/share/classes/java/util/WeakHashMap.java line 293: > >> 291: // then checks for equality >> 292: Object k = e.get(); >> 293: return key == k || key.equals(k); > > I think `key == k` is already covered by refersTo. But k could be null; checking for that here might be useful, to skip the call to equals in that case. Good point on checking k != null. A cleaner check: // then check for equality if the referent is not cleared Object k = e.get(); return k != null || key.equals(k); ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From plevart at openjdk.java.net Fri Dec 4 20:20:11 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Dec 2020 20:20:11 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:09:01 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/util/WeakHashMap.java line 293: >> >>> 291: // then checks for equality >>> 292: Object k = e.get(); >>> 293: return key == k || key.equals(k); >> >> I think `key == k` is already covered by refersTo. But k could be null; checking for that here might be useful, to skip the call to equals in that case. > > Good point on checking k != null. A cleaner check: > > // then check for equality if the referent is not cleared > Object k = e.get(); > return k != null || key.equals(k); You meant: `return k != null && key.equals(k);` right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From mchung at openjdk.java.net Fri Dec 4 20:20:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 20:20:14 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 19:47:17 GMT, Peter Levart wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java line 127: > >> 125: T got = get(); >> 126: return got != null && wr.refersTo(got); >> 127: } > > Here you could pre-screen the get() with: > > if (this.refersTo(null) != wr.refersTo(null)) return false; > > In case one of the two WeakReference(s) is cleared and the other is not, they are not equal and you don't call this.get() in such case. `expunge` is called at `get`, `put`, and `remove`. While there is a chance that a referent might be cleared, I will leave this as is and this patch simply replaces to use `refersTo`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From mchung at openjdk.java.net Fri Dec 4 20:20:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 20:20:16 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:05:23 GMT, Kevin Rushforth wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > src/java.base/share/classes/java/util/WeakHashMap.java line 437: > >> 435: int index = indexFor(h, tab.length); >> 436: Entry e = tab[index]; >> 437: while (e != null && !(e.hash == h && matchesKey(e, k)) > > This doesn't compile, which is why the checks from the GitHub actions build failed. I caught that and it's in my local repo that I haven't pushed the commit. Sorry for not syncing my branch for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From bpb at openjdk.java.net Fri Dec 4 20:35:17 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 4 Dec 2020 20:35:17 GMT Subject: Integrated: 8257750: writeBuffer field of java.io.DataOutputStream should be final In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:58:56 GMT, Brian Burkhalter wrote: > Please review this trivial change to make the `writeBuffer` array field final and move it to the beginning of the class where other fields are declared. This pull request has now been integrated. Changeset: e27ea4d1 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/e27ea4d1 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod 8257750: writeBuffer field of java.io.DataOutputStream should be final Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/1627 From plevart at openjdk.java.net Fri Dec 4 20:38:11 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Dec 2020 20:38:11 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:16:14 GMT, Mandy Chung wrote: >> src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java line 127: >> >>> 125: T got = get(); >>> 126: return got != null && wr.refersTo(got); >>> 127: } >> >> Here you could pre-screen the get() with: >> >> if (this.refersTo(null) != wr.refersTo(null)) return false; >> >> In case one of the two WeakReference(s) is cleared and the other is not, they are not equal and you don't call this.get() in such case. > > `expunge` is called at `get`, `put`, and `remove`. While there is a chance that a referent might be cleared, I will leave this as is and this patch simply replaces to use `refersTo`. You're right. Where it would matter is in expunge() where the Map keys that get polled off the reference queue are all already cleared and when HashMap.remove(key) is called with such cleared key, it is this cleared key that is the target of key.equals(other) method invocation (and not vice versa), so it doesn't matter if .get() is called on such key as it is already cleared. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From darcy at openjdk.java.net Fri Dec 4 20:39:22 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Dec 2020 20:39:22 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 16:33:15 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add class level clarification of use of uppercase for primitive conversions > Switched order of declaration of a couple of method to make the javadoc sequence easier to read src/java.base/share/classes/java/util/HexFormat.java line 740: > 738: * @param value an {@code int} value > 739: * @return the eight hexadecimal characters for the {@code int} value > 740: */ I recommend added an @see link to Integer.toHexString (and Long.toHexString for the long overload). ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From darcy at openjdk.java.net Fri Dec 4 20:43:20 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Dec 2020 20:43:20 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 16:33:15 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add class level clarification of use of uppercase for primitive conversions > Switched order of declaration of a couple of method to make the javadoc sequence easier to read Marked as reviewed by darcy (Reviewer). src/java.base/share/classes/java/util/HexFormat.java line 936: > 934: * if any of the characters is not a hexadecimal character > 935: */ > 936: public int fromHexDigits(CharSequence string) { I recommend this group of methods include an apinote explaining the differences in behavior of compared to parseInt(s, 16) and parseUnsignedInt(s, 16). ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From bchristi at openjdk.java.net Fri Dec 4 20:47:12 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 4 Dec 2020 20:47:12 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 19:51:54 GMT, Mandy Chung wrote: >> Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. >> >> The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). >> >> The new version of the test passes 100 times out of 100 on the test farm. > > Alternatively, you can simply use `test/libjdk/test/lib/util/ForceGC` in the testlibrary. Yes, I think that's a better plan, Mandy. Thanks. I'll update the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From dfuchs at openjdk.java.net Fri Dec 4 20:51:16 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Dec 2020 20:51:16 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 19:44:33 GMT, Mahendra Chhipa wrote: > jaxp.library.SimpleHttpServer > https://bugs.openjdk.java.net/browse/JDK-8212035 Changes requested by dfuchs (Reviewer). test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java line 80: > 78: creator.buildSignedMultiReleaseJar(); > 79: > 80: server = new SimpleHttpServer(TESTCONTEXT,System.getProperty("user.dir", ".")); Please add space after comma. test/lib/jdk/test/lib/net/SimpleHttpServer.java line 95: > 93: return _httpserver.getAddress().getPort(); > 94: } > 95: There are many issues with this class - using "localhost" and binding to the wildcard address among others. Having instance variables that are not final but are accessed by potentially multiple threads is another. I could also mention not using try-with-resources or the odd _name convention. It will need to be modernized if you want to put it in jdk.test.lib.net; ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From dfuchs at openjdk.java.net Fri Dec 4 20:51:17 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Dec 2020 20:51:17 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer In-Reply-To: References: Message-ID: <60CyX-zWhx9EA7xs7Kt9D0ut7hF6c3DhHUn2UaAonho=.2fee02bd-42eb-4ca5-86c6-3b200b944663@github.com> On Fri, 4 Dec 2020 20:32:02 GMT, Daniel Fuchs wrote: >> jaxp.library.SimpleHttpServer >> https://bugs.openjdk.java.net/browse/JDK-8212035 > > test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java line 80: > >> 78: creator.buildSignedMultiReleaseJar(); >> 79: >> 80: server = new SimpleHttpServer(TESTCONTEXT,System.getProperty("user.dir", ".")); > > Please add space after comma. I believe the InetAddress parameter should be preserved in order to allow test to specifically bind to the loopback address instead of the wildcard (binding to the wildcard has been a source of test instability in the past). ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From dholmes at openjdk.java.net Fri Dec 4 21:18:25 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 4 Dec 2020 21:18:25 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. Looks good - 99% sym stuff :) Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17. src/hotspot/share/opto/type.cpp line 827: > 825: tty->print("this meet t = "); mt->dump(); tty->cr(); > 826: fatal("meet not commutative"); > 827: } Merge issue?? src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226: > 224: REIFIABLE_TYPES_INSTANCEOF(JDK16, Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL), > 225: RECORDS(JDK16, Fragments.FeatureRecords, DiagKind.PLURAL), > 226: SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL), Is this changed because it is still preview? test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp line 27: > 25: #include "precompiled.hpp" > 26: > 27: #if defined(AARCH64) && !defined(ZERO) Another merge issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From darcy at openjdk.java.net Fri Dec 4 21:18:24 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Dec 2020 21:18:24 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 Message-ID: Start of JDK 17 updates. ------------- Commit messages: - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - JDK-8257450 - JDK-8257450 - JDK-8257450 Changes: https://git.openjdk.java.net/jdk/pull/1531/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257450 Stats: 7522 lines in 76 files changed: 7463 ins; 0 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From darcy at openjdk.java.net Fri Dec 4 21:18:26 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Dec 2020 21:18:26 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 07:33:25 GMT, David Holmes wrote: >> Start of JDK 17 updates. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226: > >> 224: REIFIABLE_TYPES_INSTANCEOF(JDK16, Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL), >> 225: RECORDS(JDK16, Fragments.FeatureRecords, DiagKind.PLURAL), >> 226: SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL), > > Is this changed because it is still preview? Right; JEP 397: "Sealed Classes (Second Preview)" is PTT for JDk 16. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From darcy at openjdk.java.net Fri Dec 4 21:23:18 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Dec 2020 21:23:18 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 07:38:13 GMT, David Holmes wrote: >> Start of JDK 17 updates. > > Looks good - 99% sym stuff :) > > Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17. Usual start of release update: * Expected version number updates in the make system * New set of data files to support --release 16 in javac * Update to various version-related langtools APIs and tests * Minor N -> N+1 updates in vm and vm tests One javadoc test that failed under the new version was fixed before this PR was sent out. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From erikj at openjdk.java.net Fri Dec 4 21:38:11 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Dec 2020 21:38:11 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: <5-1l9r81KZj0_g84xfhxSzfzrjggP8SzM1dpOkk5r_Q=.a8e26b00-c810-4458-abd7-131c92aeee02@github.com> On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. Build changes look good and I'm happy there are so few of them! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1531 From mchung at openjdk.java.net Fri Dec 4 22:07:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 22:07:14 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:14:13 GMT, Peter Levart wrote: >> Good point on checking k != null. A cleaner check: >> >> // then check for equality if the referent is not cleared >> Object k = e.get(); >> return k != null || key.equals(k); > > You meant: `return k != null && key.equals(k);` right? oops...yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From rriggs at openjdk.java.net Fri Dec 4 22:16:21 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Dec 2020 22:16:21 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:39:58 GMT, Joe Darcy wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Add class level clarification of use of uppercase for primitive conversions >> Switched order of declaration of a couple of method to make the javadoc sequence easier to read > > src/java.base/share/classes/java/util/HexFormat.java line 936: > >> 934: * if any of the characters is not a hexadecimal character >> 935: */ >> 936: public int fromHexDigits(CharSequence string) { > > I recommend this group of methods include an apinote explaining the differences in behavior of compared to parseInt(s, 16) and parseUnsignedInt(s, 16). Will add: * @apiNote * {@link Integer#parseInt(String, int) Integer.parseInt(s, 16)} and * {@link Integer#parseUnsignedInt(String, int) Integer.pareUnsignedInt(s, 16)} * are similar but allow all Unicode hexadecimal digits allowed by * {@link Character#digit(char, int) Character.digit(ch, 16)}. * {@code HexFormat} uses only Latin1 hexadecimal characters "0-9, "A-F", and "a-f". * {@link Integer#parseInt(String, int)} can parse signed hexadecimal strings. And similar text for Long#parseLong and Long.parseUnsignedLong ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From martin at openjdk.java.net Fri Dec 4 22:17:18 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Fri, 4 Dec 2020 22:17:18 GMT Subject: RFR: 8243614: Typo in ReentrantLock's Javadoc Message-ID: Add missing semicolon Martin's first github pr. ------------- Commit messages: - JDK-8243614-typo Changes: https://git.openjdk.java.net/jdk/pull/1633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243614 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1633/head:pull/1633 PR: https://git.openjdk.java.net/jdk/pull/1633 From mchung at openjdk.java.net Fri Dec 4 22:38:24 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Dec 2020 22:38:24 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` [v2] In-Reply-To: References: Message-ID: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - revise matchsKey to check equality if the reference is not cleared - fix typo - update copyright end year and fixup grammatical nit - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - 8256167: Convert JDK use of to - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo - minor cleanup - Merge branch 'refersto' of https://github.com/kimbarrett/openjdk-jdk into refersTo - improve refersTo0 descriptions - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d8ac76fa...72947eb3 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1609&range=01 Stats: 60 lines in 12 files changed: 7 ins; 11 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/1609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1609/head:pull/1609 PR: https://git.openjdk.java.net/jdk/pull/1609 From dholmes at openjdk.java.net Sat Dec 5 00:06:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 5 Dec 2020 00:06:11 GMT Subject: RFR: 8243614: Typo in ReentrantLock's Javadoc In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:06:03 GMT, Martin Buchholz wrote: > Add missing semicolon > > Martin's first github pr. Looks trivially fine. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1633 From iris at openjdk.java.net Sat Dec 5 01:37:14 2020 From: iris at openjdk.java.net (Iris Clark) Date: Sat, 5 Dec 2020 01:37:14 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From dlsmith at openjdk.java.net Sat Dec 5 01:52:21 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 5 Dec 2020 01:52:21 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal Message-ID: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Integration of JEP 390, addressing the following issues: 8252180: [JEP 390] Deprecate wrapper class constructors for removal 8254047: [JEP 390] Revise "value-based class" & apply to wrappers 8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased 8252183: [JEP 390] Add 'lint' warning for @ValueBased classes 8257027: [JEP 390] Diagnose synchronization on @ValueBased classes See https://github.com/openjdk/valhalla/tree/jep390 for development history. ------------- Commit messages: - Merge - 8257776: [valhalla:jep390] Add disclaimer about future changes to value-based classes - 8254275: [valhalla/jep390] Revise "value-based class" & apply to wrappers - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes - Merge - 8256663: [test] Deprecated use of new Double in jshell ImportTest - 8253962: Add @ValueBased to unmodifable Collection implementation classes - 8256002: Cleanup of Wrapper changes - Merge - 8254271: Development to deprecate wrapper class constructors for removal - ... and 2 more: https://git.openjdk.java.net/jdk/compare/93b6ab56...7c5e5bfe Changes: https://git.openjdk.java.net/jdk/pull/1636/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1636&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252180 Stats: 902 lines in 114 files changed: 489 ins; 121 del; 292 mod Patch: https://git.openjdk.java.net/jdk/pull/1636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1636/head:pull/1636 PR: https://git.openjdk.java.net/jdk/pull/1636 From kbarrett at openjdk.java.net Sat Dec 5 02:11:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 5 Dec 2020 02:11:13 GMT Subject: RFR: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:38:24 GMT, Mandy Chung wrote: >> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - revise matchsKey to check equality if the reference is not cleared > - fix typo > - update copyright end year and fixup grammatical nit > - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo > - 8256167: Convert JDK use of to > - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo > - Merge branch 'master' of https://github.com/openjdk/jdk into refersTo > - minor cleanup > - Merge branch 'refersto' of https://github.com/kimbarrett/openjdk-jdk into refersTo > - improve refersTo0 descriptions > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d8ac76fa...72947eb3 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From iignatyev at openjdk.java.net Sat Dec 5 02:19:13 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 5 Dec 2020 02:19:13 GMT Subject: RFR: 8257516: define test group for manual tests [v3] In-Reply-To: References: Message-ID: <8GE1kWzc9DSOsknqaHCgG3SCPcIvajwkoiFkmq-2pTA=.11b48e3d-33a1-49a6-a540-3ce82153773f@github.com> On Thu, 3 Dec 2020 22:54:13 GMT, Ivan ?ipka wrote: >> Defined new test groups as defined in ticket. @fguallini > > Ivan ?ipka has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8257516: define test group for manual tests LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1416 From smarks at openjdk.java.net Sat Dec 5 02:40:13 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 5 Dec 2020 02:40:13 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 19:13:45 GMT, Roger Riggs wrote: >> The preconditions aren't checked, because this is an internal method, and the code size is minimized in order to help inlining. That's also why `hugeLength` is a separate method. (I guess I could add comments to this effect.) With this in mind it's hard to reason about robustness. If prefLength is zero, this can only be because some precondition was violated (e.g., oldLength is negative). If this were to occur there doesn't seem to be any advantage choosing one undefined behavior over another. > > Is there a reason the code would not naturally work when either min or preferred is zero? > Why are their preconditions? What do they allow? > These methods are used in enough places that a slip in any of the clients would be trouble and hard to track down. The origin of this code is in collections like ArrayList that have an existing array (hence oldLength >= 0) and that need it to grow (hence minGrowth > 0). Those were the prevailing assumptions in the code from which this was derived, so they turn into preconditions here. I don't see the need to try to make this handle any more cases than it currently does. Doing so complicates the analysis and possibly the code as well. Certainly a bug in a caller might be difficult to track down, but I don't want to add argument checking or to provide "reasonable" behavior in the face of unreasonable inputs. This is an internal method; bugs in callers should be fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From smarks at openjdk.java.net Sat Dec 5 03:05:12 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 5 Dec 2020 03:05:12 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:02:33 GMT, Roger Riggs wrote: >> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: >> >> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! >> >> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. >> >> Separately, I'll work on retrofitting various call sites around the JDK to use this method. > > Nice clean description of the algorithm. For what it's worth, the following code: var list = Collections.nCopies(Integer.MAX_VALUE - 3, ""); var list2 = new ArrayList<>(list); list2.addAll(list); results in `java.lang.NegativeArraySizeException: -8` where the -8 is returned by `ArraysSupport.newLength`. This is a demonstration of the problem with overflow checking that is fixed by this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From dlsmith at openjdk.java.net Sat Dec 5 03:07:11 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 5 Dec 2020 03:07:11 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal > - Revise "value-based class" & apply to wrappers > - Define & apply annotation jdk.internal.ValueBased > - Add 'lint' warning for @ValueBased classes > - Diagnose synchronization on @ValueBased classes > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. I've updated the description to provide an overview for those unfamiliar with this work. Reviewers are welcome, including those who have previously reviewed a subset of these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1636 From mikael at openjdk.java.net Sat Dec 5 03:20:12 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 5 Dec 2020 03:20:12 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From almatvee at openjdk.java.net Sat Dec 5 05:40:17 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 5 Dec 2020 05:40:17 GMT Subject: RFR: 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource Message-ID: Fixed by using correct localized resources. ------------- Commit messages: - 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource Changes: https://git.openjdk.java.net/jdk/pull/1638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1638&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255619 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1638/head:pull/1638 PR: https://git.openjdk.java.net/jdk/pull/1638 From cay.horstmann at gmail.com Sat Dec 5 07:43:10 2020 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sat, 5 Dec 2020 08:43:10 +0100 Subject: MatchResult support for named groups In-Reply-To: References: <14517.1606845585151306433@groups.io> Message-ID: Hi Stuart, 1: If there is no match at all, then results yields the empty stream. I don't think anything else is required. 2/3: I wrote a fair number of regex patterns in Java, ever since they appeared in 2002. I can say with confidence that I never once used hitEnd/requireEnd, or seen it used. I note they occur in one file in the JDK 11 source, in the Scanner class. But not in a loop that fetches all matches, but after a single call to find or lookingAt. I think these are exceedingly uncommon. In contrast, looping over matcher.find() and extracting groups is common, and named groups are a best practice (https://eslint.org/docs/rules/prefer-named-capture-group). Cheers, Cay Il 04/12/2020 19:53, Stuart Marks ha scritto: > Hi Cay, > > Thanks for mentioning this. It's good to know that adding this provides > value to people who are actually trying to use this stuff (as opposed to > adding stuff merely for the sake of completeness, as often seems to arise). > > I've added some notes to JDK-8065554. > > Looking at this more closely, it seems to me that MatchResult ought to > include more match-result-related information that's currently only in > Matcher, namely: > > 1. whether there was a match at all > 2. hitEnd > 3. requireEnd > > If you have any thoughts on these, please let me know. > > s'marks > > On 12/2/20 2:53 AM, Cay Horstmann wrote: >> Hello, I'd like to raise awareness for >> >> https://bugs.openjdk.java.net/browse/JDK-8180352 >> https://bugs.openjdk.java.net/browse/JDK-8072984 >> https://bugs.openjdk.java.net/browse/JDK-8065554 >> >> These all ask for MatchResult.group(String name). What they don't >> mention is that this is more urgent in light of the methods >> >> Stream Matcher.results() // >> https://bugs.openjdk.java.net/browse/JDK-8071479 >> Stream Scanner.findAll(Pattern pattern) // >> https://bugs.openjdk.java.net/browse/JDK-8072722 >> >> In particular, Matcher.results() seems a cleaner way of collecting >> match results than calling while (matcher.find()). >> >> But then MatchResult needs to support the same queries that Matcher >> provides. I believe the only missing one is group(String name). >> >> Cheers, >> >> Cay >> >> NB. There are related requests that ask for finding group names in >> patterns, or for correlating group names and numbers. I have formed no >> opinion on their merits. >> -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From alanb at openjdk.java.net Sat Dec 5 08:20:12 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 5 Dec 2020 08:20:12 GMT Subject: RFR: 8243614: Typo in ReentrantLock's Javadoc In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:06:03 GMT, Martin Buchholz wrote: > Add missing semicolon > > Martin's first github pr. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1633 From martin at openjdk.java.net Sat Dec 5 08:47:12 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Sat, 5 Dec 2020 08:47:12 GMT Subject: Integrated: 8243614: Typo in ReentrantLock's Javadoc In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:06:03 GMT, Martin Buchholz wrote: > Add missing semicolon > > Martin's first github pr. This pull request has now been integrated. Changeset: c4339c30 Author: Martin Buchholz URL: https://git.openjdk.java.net/jdk/commit/c4339c30 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8243614: Typo in ReentrantLock's Javadoc Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1633 From github.com+1709517+mariusvolkhart at openjdk.java.net Sat Dec 5 12:02:26 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Sat, 5 Dec 2020 12:02:26 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v3] In-Reply-To: References: Message-ID: > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. Marius Volkhart has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Adjust test so it works with jtreg - Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. - Add test for XmlInputFactory ------------- Changes: https://git.openjdk.java.net/jdk/pull/1056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1056&range=02 Stats: 47 lines in 2 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1056/head:pull/1056 PR: https://git.openjdk.java.net/jdk/pull/1056 From herrick at openjdk.java.net Sat Dec 5 16:12:11 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Sat, 5 Dec 2020 16:12:11 GMT Subject: RFR: 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 05:33:25 GMT, Alexander Matveev wrote: > Fixed by using correct localized resources. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1638 From rriggs at openjdk.java.net Sat Dec 5 16:35:02 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 5 Dec 2020 16:35:02 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v18] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision: - Added @apiNote to fromHexDigits methods to link and compare to similar methods in Integer and Long. - Merge branch 'master' into 8251989-hex-formatter - Add class level clarification of use of uppercase for primitive conversions Switched order of declaration of a couple of method to make the javadoc sequence easier to read - Clarify that the fromHexDigit method does not use the prefix, suffix, delimiter, or uppercase parameter. - Clarify that the fromHexDigits does not use the uppercase parameter. - Increased memory to 4G for the test and add diagnostic info for OOME - Review comment updates: - misc javadoc markup fixes. - added checking of byte array sizes to generate useful exceptions if the arrays would be too large. - Small implementation cleanups - Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F. Added a test to verify isHexDigit and fromHexDigit for the entire range of chars - Merge branch 'master' into 8251989-hex-formatter - Addressed review comments on use of formatted hexadecimal strings, updated copyrights, etc. - ... and 19 more: https://git.openjdk.java.net/jdk/compare/4e2842b3...af7b1fa9 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/0a8088b1..af7b1fa9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=16-17 Stats: 24226 lines in 635 files changed: 18266 ins; 3456 del; 2504 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From naoto at openjdk.java.net Sat Dec 5 18:09:12 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 5 Dec 2020 18:09:12 GMT Subject: RFR: 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 05:33:25 GMT, Alexander Matveev wrote: > Fixed by using correct localized resources. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1638 From github.com+20868526+mikeedgar at openjdk.java.net Sun Dec 6 00:00:24 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Sun, 6 Dec 2020 00:00:24 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v2] In-Reply-To: References: Message-ID: > Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. > > Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). Michael Edgar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Update test for jtreg - 8255918: Throw XMLStreamExceptions from XMLStreamFilterImpl constructor ------------- Changes: https://git.openjdk.java.net/jdk/pull/1209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=01 Stats: 103 lines in 2 files changed: 91 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1209/head:pull/1209 PR: https://git.openjdk.java.net/jdk/pull/1209 From github.com+20868526+mikeedgar at openjdk.java.net Sun Dec 6 00:05:17 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Sun, 6 Dec 2020 00:05:17 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 22:14:47 GMT, Michael Edgar wrote: > Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. > > Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). Test has been updated for `jtreg`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From mchung at openjdk.java.net Sun Dec 6 00:11:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Sun, 6 Dec 2020 00:11:14 GMT Subject: Integrated: 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote: > This patch replaces some uses of `Reference::get` to `Reference::refersTo` to avoid keeping a referent strongly reachable that could cause unnecessary delay in collecting such object. I only made change in some but not all classes in core libraries when working with Kim on `Reference::refersTo`. The remaining uses are left for the component owners to convert at appropriate time. This pull request has now been integrated. Changeset: 972bc3b4 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/972bc3b4 Stats: 60 lines in 12 files changed: 7 ins; 11 del; 42 mod 8256167: Convert JDK use of `Reference::get` to `Reference::refersTo` Reviewed-by: sspitsyn, shade, dfuchs, alanb, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1609 From isipka at openjdk.java.net Sun Dec 6 17:29:27 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Sun, 6 Dec 2020 17:29:27 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v3] In-Reply-To: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: > Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1578/files - new: https://git.openjdk.java.net/jdk/pull/1578/files/fa23de7f..05e3dd2f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=01-02 Stats: 27 lines in 1 file changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1578/head:pull/1578 PR: https://git.openjdk.java.net/jdk/pull/1578 From jboes at openjdk.java.net Mon Dec 7 09:34:15 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 7 Dec 2020 09:34:15 GMT Subject: Integrated: 8256679: Update serialization javadoc once JOSS changes for records are complete In-Reply-To: References: Message-ID: <_r4_LdFWVNA74vm_NNYPgBpM8VmVfwQLEYRoLSPQL34=.757a754e-b84c-4c48-a656-5d899df28582@github.com> On Wed, 2 Dec 2020 14:51:23 GMT, Julia Boes wrote: > Now that the changes for record serialization are integrated into the Java Object Serialization Specification, this change updates the serialization javadocs in ObjectInputStream, ObjectOutputStream, Serializable and java.lang.Record. Additionally, the suppression of preview related warnings is removed in ObjectOutputStream and ObjectStreamClass. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8257592 This pull request has now been integrated. Changeset: d05401d8 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/d05401d8 Stats: 58 lines in 5 files changed: 8 ins; 34 del; 16 mod 8256679: Update serialization javadoc once JOSS changes for records are complete Reviewed-by: chegar, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/1564 From chegar at openjdk.java.net Mon Dec 7 09:57:24 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 7 Dec 2020 09:57:24 GMT Subject: RFR: 8255560: Class::isRecord should check that the current class is final and not abstract [v5] In-Reply-To: References: Message-ID: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Remove unused test helper method - Merge branch 'master' into isRecord - fix issue in ByteCodeLoader - review comments - Mandy's review comments - Initial changes for 8255560 Class::isRecord should check that the current class is final and not abstract ------------- Changes: https://git.openjdk.java.net/jdk/pull/1543/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1543&range=04 Stats: 230 lines in 3 files changed: 208 ins; 3 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1543/head:pull/1543 PR: https://git.openjdk.java.net/jdk/pull/1543 From chegar at openjdk.java.net Mon Dec 7 11:06:16 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 7 Dec 2020 11:06:16 GMT Subject: Integrated: 8255560: Class::isRecord should check that the current class is final and not abstract In-Reply-To: References: Message-ID: <2KV--wcwKq3IgX2jTKuS6naqjpAMgBaQX36-sQKZ-CY=.7f8dbd15-2892-4502-88ff-d6a85442a72a@github.com> On Tue, 1 Dec 2020 19:34:11 GMT, Chris Hegarty wrote: > Update Class::isRecord to only return true for classes that are final. > > The removal of non-specified JVM checks on classes with a Record Attribute (see JDK-8255342), has resulted in more types of loadable classes that may contain a Record Attribute. Since these checks are not performed by the JVM anymore, Class::isRecord, and by extension Class::getRecordComponents, may return true or component values, respectively, for classes that are not well-formed record classes (as per the JLS), .e.g. non-final or abstract classes, that contain a record Attribute. > > Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record. Some points from the Java Language Specification for record classes: > > 1. It is a compile-time error if a record declaration has the modifier abstract. > 2. A record declaration is implicitly final. > 3. The direct superclass type of a record class is Record. > > Class::isRecord already ensures no.3. This issue proposes to add explicit checks in Core Reflection to ensure no.1 and no.2, since the JVM now allows such classes that contain a Record Attribute to be loaded. This pull request has now been integrated. Changeset: 5a03e476 Author: Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/5a03e476 Stats: 230 lines in 3 files changed: 208 ins; 3 del; 19 mod 8255560: Class::isRecord should check that the current class is final and not abstract Reviewed-by: mchung, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/1543 From jvernee at openjdk.java.net Mon Dec 7 11:11:18 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Dec 2020 11:11:18 GMT Subject: Integrated: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle In-Reply-To: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com> References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com> Message-ID: On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee wrote: > This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396 > > There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8257187 This pull request has now been integrated. Changeset: 04ce8e38 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/04ce8e38 Stats: 321 lines in 4 files changed: 264 ins; 7 del; 50 mod 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle Reviewed-by: mcimadamore, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1468 From jlahoda at openjdk.java.net Mon Dec 7 11:14:14 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Dec 2020 11:14:14 GMT Subject: Integrated: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda wrote: > This pull request replaces https://github.com/openjdk/jdk/pull/1227. > > From the original PR: > >> Please review the code for the second iteration of sealed classes. In this iteration we are: >> >> * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies >> >> * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface >> >> * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] >> >> * adding code to make sure that annotations can't be sealed >> >> * improving some tests >> >> >> TIA >> >> Related specs: >> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) >> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) >> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) > > This PR strives to reflect the review comments from 1227: > * adjustments to javadoc of j.l.Class methods > * package access checks in Class.getPermittedSubclasses() > * fixed to the narrowing conversion/castability as pointed out by Maurizio This pull request has now been integrated. Changeset: 637b0c64 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/637b0c64 Stats: 1138 lines in 16 files changed: 1055 ins; 11 del; 72 mod 8246778: Compiler implementation for Sealed Classes (Second Preview) Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Reviewed-by: lfoltan, mchung, alanb, mcimadamore, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1483 From ihse at openjdk.java.net Mon Dec 7 14:27:45 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Dec 2020 14:27:45 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: Message-ID: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> > 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. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move to share/data, and move jdwp.spec to java.se ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/8e775e40..f0047704 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00-01 Stats: 56 lines in 1565 files changed: 1 ins; 0 del; 55 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 From ihse at openjdk.java.net Mon Dec 7 14:28:06 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Dec 2020 14:28:06 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie wrote: >> @erikj79 Good point, that makes much more sense. > > I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme: > > src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java > native/include/*.{h,hpp} > $LIBRARY/*.{c,cpp} > conf/* > legal/* > data/* > man/* > lib/* > > where: > > - $MODULE is a module name (_e.g._, `java.base`); > > - The `share` directory contains shared, cross-platform code, as > before; > > - The `$OS` directory contains operating-system-specific code, as > before, where `$OS` is one of `unix`, `windows`, _etc._; > > - The `classes` directory contains Java source files and resource files > organized into a directory tree reflecting their API `$PACKAGE` > hierarchy, as before; > > - The `native` directory contains C or C++ source files, as before but > organized differently: > > - The `include` directory contains C or C++ header files intended to > be exported for external use (_e.g._, `jni.h`); > > - C or C++ source files are placed in a `$LIBRARY` directory, whose > name is that of the shared library or DLL into which the compiled > code will be linked (_e.g._, `libjava` or `libawt`); and, finally, > > - The `conf` directory contains configuration files meant to be edited > by end users (_e.g._, `net.properties`). > > - The `legal` directory contains legal notices. > > - The `data` directory contains data files needed for building the module. > > - The `man` directory contains man pages in nroff or markdown format. > > - The `lib` directory contains configuration files not meant to be edited > by end users. > > Rendered as markdown, it would look somewhat like this: > > src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java > native/include/*.{h,hpp} > $LIBRARY/*.{c,cpp} > conf/* > legal/* > data/* > man/* > lib/* > > where: > > - $MODULE is a module name (_e.g._, `java.base`); > > - The `share` directory contains shared, cross-platform code, as > before; > > - The `$OS` directory contains operating-system-specific code, as > before, where `$OS` is one of `unix`, `windows`, _etc._; > > - The `classes` directory contains Java source files and resource files > organized into a directory tree reflecting their API `$PACKAGE` > hierarchy, as before; > > - The `native` directory contains C or C++ source files, as before but > organized differently: > > - The `include` directory contains C or C++ header files intended to > be exported for external use (_e.g._, `jni.h`); > > - C or C++ source files are placed in a `$LIBRARY` directory, whose > name is that of the shared library or DLL into which the compiled > code will be linked (_e.g._, `libjava` or `libawt`); and, finally, > > - The `conf` directory contains configuration files meant to be edited > by end users (_e.g._, `net.properties`). > > - The `legal` directory contains legal notices. > > - The `data` directory contains data files needed for building the module. > > - The `man` directory contains man pages in nroff or markdown format. > > - The `lib` directory contains configuration files not meant to be edited > by end users. I hope I understood the purpose of the `lib` directory correctly. Our only instance of this is for `java.base/*/lib/security/default.policy`. I also noted that jdk.hotspot.agent violates this scheme by having a top-level `test` and `doc` directories, apart from `share` and the OS directories. The purposes of these two directories are not clear to me. The tests in `test` are definitely never executed. I don't know if this is an omission, or if they should be removed. The documentation in `doc` is not exported to the end product, nor is it references in any developer documentation. That too should either be removed, or moved to a more suitable home. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Dec 7 14:28:05 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Dec 2020 14:28:05 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote: >> Regarding the chosen layout. Did you consider following the existing pattern of src//{share,}/data? > > @erikj79 Good point, that makes much more sense. I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme: src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java native/include/*.{h,hpp} $LIBRARY/*.{c,cpp} conf/* legal/* data/* man/* lib/* where: - $MODULE is a module name (_e.g._, `java.base`); - The `share` directory contains shared, cross-platform code, as before; - The `$OS` directory contains operating-system-specific code, as before, where `$OS` is one of `unix`, `windows`, _etc._; - The `classes` directory contains Java source files and resource files organized into a directory tree reflecting their API `$PACKAGE` hierarchy, as before; - The `native` directory contains C or C++ source files, as before but organized differently: - The `include` directory contains C or C++ header files intended to be exported for external use (_e.g._, `jni.h`); - C or C++ source files are placed in a `$LIBRARY` directory, whose name is that of the shared library or DLL into which the compiled code will be linked (_e.g._, `libjava` or `libawt`); and, finally, - The `conf` directory contains configuration files meant to be edited by end users (_e.g._, `net.properties`). - The `legal` directory contains legal notices. - The `data` directory contains data files needed for building the module. - The `man` directory contains man pages in nroff or markdown format. - The `lib` directory contains configuration files not meant to be edited by end users. Rendered as markdown, it would look somewhat like this: src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java native/include/*.{h,hpp} $LIBRARY/*.{c,cpp} conf/* legal/* data/* man/* lib/* where: - $MODULE is a module name (_e.g._, `java.base`); - The `share` directory contains shared, cross-platform code, as before; - The `$OS` directory contains operating-system-specific code, as before, where `$OS` is one of `unix`, `windows`, _etc._; - The `classes` directory contains Java source files and resource files organized into a directory tree reflecting their API `$PACKAGE` hierarchy, as before; - The `native` directory contains C or C++ source files, as before but organized differently: - The `include` directory contains C or C++ header files intended to be exported for external use (_e.g._, `jni.h`); - C or C++ source files are placed in a `$LIBRARY` directory, whose name is that of the shared library or DLL into which the compiled code will be linked (_e.g._, `libjava` or `libawt`); and, finally, - The `conf` directory contains configuration files meant to be edited by end users (_e.g._, `net.properties`). - The `legal` directory contains legal notices. - The `data` directory contains data files needed for building the module. - The `man` directory contains man pages in nroff or markdown format. - The `lib` directory contains configuration files not meant to be edited by end users. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From rriggs at openjdk.java.net Mon Dec 7 15:08:12 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Dec 2020 15:08:12 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class" & apply to wrappers (dlsmith) > - Define & apply annotation jdk.internal.ValueBased (rriggs) > - Add 'lint' warning for @ValueBased classes (sadayapalam) > - Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. For the core libraries parts looks ok. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1636 From rriggs at openjdk.java.net Mon Dec 7 15:49:12 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Dec 2020 15:49:12 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v3] In-Reply-To: References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: On Sun, 6 Dec 2020 17:29:27 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java test/jdk/java/lang/Thread/UncaughtExceptionsTest.java line 68: > 66: @Test(dataProvider = "testCases") > 67: public void test(String className, int exitValue, String stdOutMatch, String stdErrMatch) throws Throwable { > 68: ProcessBuilder processBuilder = ProcessTools.createJavaProcessBuilder(String.format("Seppuku$%s",className)); The class renaming looks incomplete. Here and in the error texts above. Seppuku does not look right as the host class for the test, they are nested classes of UncaughtExceptionsTest. ------------- PR: https://git.openjdk.java.net/jdk/pull/1578 From hseigel at openjdk.java.net Mon Dec 7 15:53:14 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 7 Dec 2020 15:53:14 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class" & apply to wrappers (dlsmith) > - Define & apply annotation jdk.internal.ValueBased (rriggs) > - Add 'lint' warning for @ValueBased classes (sadayapalam) > - Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. The hotspot changes look good. In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent. Currently, it only tests primitive classes. ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1636 From rriggs at openjdk.java.net Mon Dec 7 16:08:13 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Dec 2020 16:08:13 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 02:37:55 GMT, Stuart Marks wrote: >> Is there a reason the code would not naturally work when either min or preferred is zero? >> Why are their preconditions? What do they allow? >> These methods are used in enough places that a slip in any of the clients would be trouble and hard to track down. > > The origin of this code is in collections like ArrayList that have an existing array (hence oldLength >= 0) and that need it to grow (hence minGrowth > 0). Those were the prevailing assumptions in the code from which this was derived, so they turn into preconditions here. I don't see the need to try to make this handle any more cases than it currently does. Doing so complicates the analysis and possibly the code as well. Certainly a bug in a caller might be difficult to track down, but I don't want to add argument checking or to provide "reasonable" behavior in the face of unreasonable inputs. This is an internal method; bugs in callers should be fixed. The algorithm can be well defined for minGrowth and prefGrowth == 0 without extra checks or exceptions with a careful look at the inequality checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From jlahoda at openjdk.java.net Mon Dec 7 16:13:13 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Dec 2020 16:13:13 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com> On Sat, 5 Dec 2020 03:17:56 GMT, Mikael Vidstedt wrote: >> Start of JDK 17 updates. > > Marked as reviewed by mikael (Reviewer). The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these may need an update. Sorry about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From vromero at openjdk.java.net Mon Dec 7 16:17:11 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 7 Dec 2020 16:17:11 GMT Subject: Withdrawn: 8246778: Compiler implementation for Sealed Classes (Second Preview) In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero wrote: > Please review the code for the second iteration of sealed classes. In this iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies > - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface > - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class[] instead of the previous ClassDesc[] > - adding code to make sure that annotations can't be sealed > - improving some tests > > TIA > > Related specs: > [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) > [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) > [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1227 From lfoltan at openjdk.java.net Mon Dec 7 16:25:13 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 7 Dec 2020 16:25:13 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Mon, 7 Dec 2020 15:50:55 GMT, Harold Seigel wrote: >> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). >> >> Development has been broken into 5 tasks, each with its own JBS issue: >> - Deprecate wrapper class constructors for removal (rriggs) >> - Revise "value-based class" & apply to wrappers (dlsmith) >> - Define & apply annotation jdk.internal.ValueBased (rriggs) >> - Add 'lint' warning for @ValueBased classes (sadayapalam) >> - Diagnose synchronization on @ValueBased classes (lfoltan) >> >> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) >> >> CSRs have also been completed or are nearly complete: >> >> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation >> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" >> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings >> >> Here's an overview of the files changed: >> >> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. >> >> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. >> >> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. >> >> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. >> >> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. >> >> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. >> >> - `src/java.management.rmi`: removing uses of wrapper class constructors. >> >> - `src/java.xml`: removing uses of wrapper class constructors. >> >> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. >> >> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) >> >> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests >> >> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics >> >> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. > > The hotspot changes look good. In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent. Currently, it only tests primitive classes. @hseigel thank you for the review. I have created https://bugs.openjdk.java.net/browse/JDK-8257836 as an RFE to address additional testing. Lois ------------- PR: https://git.openjdk.java.net/jdk/pull/1636 From sundar at openjdk.java.net Mon Dec 7 16:41:22 2020 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 7 Dec 2020 16:41:22 GMT Subject: RFR: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input Message-ID: Safe URI encode logic adopted from UnixUriUtils. ------------- Commit messages: - 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input Changes: https://git.openjdk.java.net/jdk/pull/1669/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1669&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242258 Stats: 218 lines in 2 files changed: 206 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1669/head:pull/1669 PR: https://git.openjdk.java.net/jdk/pull/1669 From asemenyuk at openjdk.java.net Mon Dec 7 17:02:17 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 7 Dec 2020 17:02:17 GMT Subject: RFR: 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 05:33:25 GMT, Alexander Matveev wrote: > Fixed by using correct localized resources. Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1638 From mcimadamore at openjdk.java.net Mon Dec 7 17:28:12 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 7 Dec 2020 17:28:12 GMT Subject: Integrated: 8257186: Size of heap segments is not computed correctlyFix overflow in size computation for heap segments In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 18:29:42 GMT, Maurizio Cimadamore wrote: > There is a subtle bug in the heap segment factories: the byte size is computed using an int multiplication instead of a long multiplication. Because of that, it is possible to observe overflow when creating segments out of arrays whose carrier has a byte size greater than one. This pull request has now been integrated. Changeset: bbc44f57 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/bbc44f57 Stats: 29 lines in 2 files changed: 21 ins; 0 del; 8 mod 8257186: Size of heap segments is not computed correctlyFix overflow in size computation for heap segments Reviewed-by: jvernee, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1466 From joehw at openjdk.java.net Mon Dec 7 17:40:16 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Dec 2020 17:40:16 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v3] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 12:02:26 GMT, Marius Volkhart wrote: >> The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. >> >> The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. > > Marius Volkhart has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Adjust test so it works with jtreg > - Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event > > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. > - Add test for XmlInputFactory src/java.xml/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java line 136: > 134: if (streamReader.standaloneSet()) { > 135: sdEvent.setStandalone(streamReader.isStandalone()); > 136: } The change looked fine at the first glance. However, when I looked at your test, I noticed that in your first test case, isStandalone will return true. This is because standalone was initiated as true and with the added condition, setStandalone is skipped. To fix the issue, consider, instead of making it conditional, adding standaloneSet to the setStandalone method. Pls update the copyright year at line 2, e.g. 2016 -> 2020. test/jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java line 22: > 20: > 21: @Test > 22: void startDocumentEvent_standaloneSet() throws XMLStreamException { Instead of creating a new test, add this test case to: test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/EventReaderTest.java update the copyright year: add "2020," update class description: add 8256515 to the bug tag: @bug 8204329 8256515 change the name of the test case to sth like: testStandaloneSet test/jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java line 25: > 23: var factory = XMLInputFactory.newInstance(); > 24: var xml = """ > 25: """; There are three test cases here. Let's use DataProvider, sth. like {"", false, false}. The test then will take three parameters, e.g. xml, standalone, standaloneSet, and make two assertEquals ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From joehw at openjdk.java.net Mon Dec 7 17:40:18 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Dec 2020 17:40:18 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v3] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 00:32:26 GMT, Joe Wang wrote: >> Marius Volkhart has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Adjust test so it works with jtreg >> - Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event >> >> The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. >> >> The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. >> - Add test for XmlInputFactory > > test/jdk/javax/xml/jaxp/8256515/XmlInputFactoryTest.java line 25: > >> 23: var factory = XMLInputFactory.newInstance(); >> 24: var xml = """ >> 25: """; > > There are three test cases here. Let's use DataProvider, sth. like {"", false, false}. The test then will take three parameters, e.g. xml, standalone, standaloneSet, and make two assertEquals And while we are here, I'm not against using new features, we actually have done a lot over time. But unless there's a clear advantage, I'd keep the code (esp. tests) compatible with 8 since it's very likely changes will be backported. With that, I would recommend not using var and text blocks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From mcimadamore at openjdk.java.net Mon Dec 7 17:44:20 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 7 Dec 2020 17:44:20 GMT Subject: RFR: 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary Message-ID: This simple patch updates the jaavdoc in the module-info file of jdk.incubator.foreign to reflect the fact that support of foreign function calls has been added. ------------- Commit messages: - Fix module-info javadoc Changes: https://git.openjdk.java.net/jdk/pull/1671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257194 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1671/head:pull/1671 PR: https://git.openjdk.java.net/jdk/pull/1671 From jboes at openjdk.java.net Mon Dec 7 17:52:26 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 7 Dec 2020 17:52:26 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record Message-ID: This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. The following rules were applied: - 'class' and/or 'interface' are used when referring to the class/interface itself - 'type' is used when referring to the type of a variable or expression ------------- Commit messages: - replace one more occurrence - change type to class in java.lang.Record - change type to class in Enum.java Changes: https://git.openjdk.java.net/jdk/pull/1670/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1670&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257639 Stats: 24 lines in 2 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/1670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1670/head:pull/1670 PR: https://git.openjdk.java.net/jdk/pull/1670 From sgehwolf at openjdk.java.net Mon Dec 7 17:55:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 7 Dec 2020 17:55:18 GMT Subject: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems Message-ID: This has been implemented for cgroups v1 with [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was lacking some tooling support for cgroups v2. With podman 2.2.0 release this could now be implemented (and tested). The idea is the same as for the cgroups v1 fix. If we've got no swap limit capabilities, return the memory limit only. Note that for cgroups v2 doesn't implement CgroupV1Metrics (obviously) and, thus, doesn't have `getMemoryAndSwapFailCount()` and `getMemoryAndSwapMaxUsage()`. Testing: - [x] submit testing - [x] container tests on cgroups v2 with swapaccount=0. - [x] Manual container tests involving `-XshowSettings:system` on cgroups v2. Thoughts? ------------- Commit messages: - 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems Changes: https://git.openjdk.java.net/jdk/pull/1672/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1672&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253797 Stats: 45 lines in 2 files changed: 24 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1672.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1672/head:pull/1672 PR: https://git.openjdk.java.net/jdk/pull/1672 From joehw at openjdk.java.net Mon Dec 7 18:01:16 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Dec 2020 18:01:16 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v2] In-Reply-To: References: Message-ID: <1KM_AqbgbZjaQefWH0ghLKcHPi9nVEgJwHDU7IHBY3M=.55315160-9d6d-4613-8028-235fce61fd23@github.com> On Sun, 6 Dec 2020 00:00:24 GMT, Michael Edgar wrote: >> Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. >> >> Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). > > Michael Edgar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Update test for jtreg > - 8255918: Throw XMLStreamExceptions from XMLStreamFilterImpl constructor I left comments the other day but forgot to submit. I've adjusted them based on your new changes. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java line 68: > 66: * the filter to apply to the reader > 67: * @throws XMLStreamException > 68: * when an XMLStreamException is thrown when {@code XMLStreamException} is preferable. test/jdk/javax/xml/jaxp/parsers/8255918/XMLStreamReaderFilterTest.java line 1: > 1: /* Please move the test to test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest Once this is done, run tier2 test instead of tier1. test/jdk/javax/xml/jaxp/parsers/8255918/XMLStreamReaderFilterTest.java line 38: > 36: > 37: static final String XMLSOURCE1 = "\n" > 38: + " \n" Change to sth like the following: /* * @test * @bug 8255918 * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest * @run testng stream.XMLStreamFilterTest.XMLStreamReaderFilterTest * @summary (general description is fine as future tests can be added, but add javadoc to the test itself) */ test/jdk/javax/xml/jaxp/parsers/8255918/XMLStreamReaderFilterTest.java line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: */ Add package stream.XMLStreamFilterTest; test/jdk/javax/xml/jaxp/parsers/8255918/XMLStreamReaderFilterTest.java line 75: > 73: > 74: assertTrue(thrown instanceof XMLStreamException, "Missing or unexpected exception type: " + String.valueOf(thrown)); > 75: assertEquals(EXPECTED_MESSAGE1, thrown.getMessage(), "Unexpected exception message: " + thrown.getMessage()); It would be good/sufficient to verify XMLStreamException with assertThrows. Checking the message details can be fragile. test/jdk/javax/xml/jaxp/parsers/8255918/XMLStreamReaderFilterTest.java line 58: > 56: * @modules java.xml > 57: * @run testng/othervm XMLStreamReaderFilterTest > 58: * Tags are added in the class description. Change this to a TestCase javadoc or note. ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From almatvee at openjdk.java.net Mon Dec 7 18:14:12 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 7 Dec 2020 18:14:12 GMT Subject: Integrated: 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 05:33:25 GMT, Alexander Matveev wrote: > Fixed by using correct localized resources. This pull request has now been integrated. Changeset: a265c201 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/a265c201 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource Reviewed-by: herrick, naoto, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/1638 From joehw at openjdk.java.net Mon Dec 7 18:18:14 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Dec 2020 18:18:14 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v2] In-Reply-To: <1KM_AqbgbZjaQefWH0ghLKcHPi9nVEgJwHDU7IHBY3M=.55315160-9d6d-4613-8028-235fce61fd23@github.com> References: <1KM_AqbgbZjaQefWH0ghLKcHPi9nVEgJwHDU7IHBY3M=.55315160-9d6d-4613-8028-235fce61fd23@github.com> Message-ID: On Wed, 18 Nov 2020 07:18:16 GMT, Joe Wang wrote: >> Michael Edgar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Update test for jtreg >> - 8255918: Throw XMLStreamExceptions from XMLStreamFilterImpl constructor > > test/jdk/javax/xml/jaxp/parsers/8255918/XMLStreamReaderFilterTest.java line 38: > >> 36: >> 37: static final String XMLSOURCE1 = "\n" >> 38: + " \n" > > Change to sth like the following: > /* > * @test > * @bug 8255918 > * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest > * @run testng stream.XMLStreamFilterTest.XMLStreamReaderFilterTest > * @summary (general description is fine as future tests can be added, but add javadoc to the test itself) > */ This comment was shown under "static final String XMLSOURCE1" in the email, though in "Files changed" pane it still is right below the class description "JDK-8255918". The comment meant to be class description, replacing "JDK-8255918". ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From dfuchs at openjdk.java.net Mon Dec 7 18:25:15 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 7 Dec 2020 18:25:15 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 17:31:34 GMT, Julia Boes wrote: > This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. > > The following rules were applied: > - 'class' and/or 'interface' are used when referring to the class/interface itself > - 'type' is used when referring to the type of a variable or expression src/java.base/share/classes/java/lang/Enum.java line 62: > 60: * java.util.EnumMap map} implementations are available. > 61: * > 62: * @param The enum class subclass I wonder about this one, given that `` is a type. It sounds strange to me - even though I understand that what is meant is that this type should point to a class (a subclass of `java.lang.Enum`). ------------- PR: https://git.openjdk.java.net/jdk/pull/1670 From mchung at openjdk.java.net Mon Dec 7 19:11:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 7 Dec 2020 19:11:13 GMT Subject: RFR: 8257845: Integrate JEP 390 In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class" & apply to wrappers (dlsmith) > - Define & apply annotation jdk.internal.ValueBased (rriggs) > - Add 'lint' warning for @ValueBased classes (sadayapalam) > - Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. core-libs and hotspot change look okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1636 From bchristi at openjdk.java.net Mon Dec 7 19:30:28 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 7 Dec 2020 19:30:28 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v2] In-Reply-To: References: Message-ID: > Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. > > The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). > > The new version of the test passes 100 times out of 100 on the test farm. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8200102 - Use existing ForceGC class in the test lib - Add gcAwait() mechanism ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1630/files - new: https://git.openjdk.java.net/jdk/pull/1630/files/a66308e8..a6d58148 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1630&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1630&range=00-01 Stats: 10552 lines in 197 files changed: 6632 ins; 3120 del; 800 mod Patch: https://git.openjdk.java.net/jdk/pull/1630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1630/head:pull/1630 PR: https://git.openjdk.java.net/jdk/pull/1630 From jjg at openjdk.java.net Mon Dec 7 19:35:17 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 7 Dec 2020 19:35:17 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> 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. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Move to share/data, and move jdwp.spec to java.se I have reviewed all lines in the patch file with or near instances of `jdk.compiler` ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From darcy at openjdk.java.net Mon Dec 7 19:38:41 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Dec 2020 19:38:41 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: References: Message-ID: > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - JDK-8257450 - JDK-8257450 - JDK-8257450 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/4187d66f..f6a64473 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=00-01 Stats: 12681 lines in 254 files changed: 8255 ins; 3285 del; 1141 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From darcy at openjdk.java.net Mon Dec 7 19:50:16 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Dec 2020 19:50:16 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com> References: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com> Message-ID: <7YT7teNjF9GmNGWPa_u40xyn_BGgZdxNhcjls6u1Hjs=.5d7bad6b-12ad-4d20-a8ad-d31a74c7a392@github.com> On Mon, 7 Dec 2020 16:10:42 GMT, Jan Lahoda wrote: > > > The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these may need an update. Sorry about that. After a merge, the tests in that directory still pass. Will keep merging in new changes and do at least more more test run before pushing. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From hseigel at openjdk.java.net Mon Dec 7 19:56:20 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 7 Dec 2020 19:56:20 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended Message-ID: Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8256867: Classes with empty PermittedSubclasses attribute cannot be extended Changes: https://git.openjdk.java.net/jdk/pull/1675/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1675&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256867 Stats: 156 lines in 8 files changed: 100 ins; 13 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/1675.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1675/head:pull/1675 PR: https://git.openjdk.java.net/jdk/pull/1675 From jvernee at openjdk.java.net Mon Dec 7 19:57:12 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Dec 2020 19:57:12 GMT Subject: RFR: 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 17:38:40 GMT, Maurizio Cimadamore wrote: > This simple patch updates the jaavdoc in the module-info file of jdk.incubator.foreign to reflect the fact that support of foreign function calls has been added. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1671 From mchung at openjdk.java.net Mon Dec 7 20:00:23 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 7 Dec 2020 20:00:23 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:30:28 GMT, Brent Christian wrote: >> Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. >> >> The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). >> >> The new version of the test passes 100 times out of 100 on the test farm. > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8200102 > - Use existing ForceGC class in the test lib > - Add gcAwait() mechanism Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From alanb at openjdk.java.net Mon Dec 7 20:05:17 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Dec 2020 20:05:17 GMT Subject: RFR: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 16:35:52 GMT, Athijegannathan Sundararajan wrote: > Safe URI encode logic adopted from UnixUriUtils. test/jdk/jdk/internal/jrtfs/Test8242258.java line 40: > 38: import static org.testng.Assert.assertEquals; > 39: > 40: public class Test8242258 { I think it would be better to create something like UriTests that we can add further tests for jrtfs URIs as they arise. test/jdk/jdk/internal/jrtfs/Test8242258.java line 60: > 58: { "xyz ", "jrt:/xyz%20" }, > 59: { "xy z", "jrt:/xy%20z" }, > 60: }; One other thing we test here is a malformed escape pair, e.g. "jrt:/%5" and check that getPath(URI) throws IAE. ------------- PR: https://git.openjdk.java.net/jdk/pull/1669 From isipka at openjdk.java.net Mon Dec 7 20:15:29 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 7 Dec 2020 20:15:29 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v4] In-Reply-To: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: > Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision: - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1578/files - new: https://git.openjdk.java.net/jdk/pull/1578/files/05e3dd2f..c94ef2c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1578&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1578/head:pull/1578 PR: https://git.openjdk.java.net/jdk/pull/1578 From isipka at openjdk.java.net Mon Dec 7 20:15:30 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 7 Dec 2020 20:15:30 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v3] In-Reply-To: References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: On Mon, 7 Dec 2020 15:46:11 GMT, Roger Riggs wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8166026: Refactor java/lang shell tests to java > > test/jdk/java/lang/Thread/UncaughtExceptionsTest.java line 68: > >> 66: @Test(dataProvider = "testCases") >> 67: public void test(String className, int exitValue, String stdOutMatch, String stdErrMatch) throws Throwable { >> 68: ProcessBuilder processBuilder = ProcessTools.createJavaProcessBuilder(String.format("Seppuku$%s",className)); > > The class renaming looks incomplete. Here and in the error texts above. > Seppuku does not look right as the host class for the test, they are nested classes of UncaughtExceptionsTest. Indeed. Running tests was succeeding because old class files were in place. So running tests is insufficient, one should run them with a pristine directory every time. ------------- PR: https://git.openjdk.java.net/jdk/pull/1578 From jjg at openjdk.java.net Mon Dec 7 20:18:16 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 7 Dec 2020 20:18:16 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - JDK-8257450 > - JDK-8257450 > - JDK-8257450 I've read all the files, and approve all the langtools related ones (i.e. not hotspot) As you've noticed elsewhere, there's a pending conflict with Magnus' work to move files around. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 108: > 106: > 107: /** > 108: * 16, tbd The "tbd" can presumably be filled in now test/jdk/java/lang/module/ClassFileVersionsTest.java line 107: > 105: { 61, 0, Set.of(STATIC, TRANSITIVE) }, > 106: > 107: { 62, 0, Set.of()}, // JDK 18 This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release? test/langtools/tools/javac/preview/classReaderTest/Client.preview.out line 1: > 1: - compiler.warn.preview.feature.use.classfile: Bar.class, 17 Is this a test can could be automated? (i.e. no manual change per release?) test/langtools/tools/javac/versions/Versions.java line 26: > 24: /* > 25: * @test > 26: * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545 8000961 8030610 8028546 8188870 8173382 8173382 8193290 8205619 8028563 8245147 8245586 8257453 long lines are annoying test/langtools/tools/javac/versions/Versions.java line 297: > 295: expectedPass(args, List.of("New7.java", "New8.java", "New10.java", "New11.java", > 296: "New14.java", "New15.java")); > 297: expectedFail(args, List.of("New16.java")); (minor) looks like bad indentation ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1531 From jlahoda at openjdk.java.net Mon Dec 7 20:18:21 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Dec 2020 20:18:21 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - JDK-8257450 > - JDK-8257450 > - JDK-8257450 Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From jwilhelm at openjdk.java.net Mon Dec 7 20:25:16 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 7 Dec 2020 20:25:16 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - JDK-8257450 > - JDK-8257450 > - JDK-8257450 Marked as reviewed by jwilhelm (Reviewer). src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 234: > 232: * @since 17 > 233: */ > 234: RELEASE_17; Would it make sense to have a RELEASE_LATEST for the cases that are just updated to the latest release every six months? ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 7 20:35:19 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 7 Dec 2020 20:35:19 GMT Subject: RFR: 6882207: Convert javap to use diamond operator internally Message-ID: 6882207: Convert javap to use diamond operator internally ------------- Commit messages: - 6882207: Convert javap to use diamond operator internally Changes: https://git.openjdk.java.net/jdk/pull/1677/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1677&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6882207 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1677/head:pull/1677 PR: https://git.openjdk.java.net/jdk/pull/1677 From herrick at openjdk.java.net Mon Dec 7 20:36:22 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 7 Dec 2020 20:36:22 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 Message-ID: increase retries and timeout increasing in runMsiexecWithRetries ------------- Commit messages: - JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 Changes: https://git.openjdk.java.net/jdk/pull/1676/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1676&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257539 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1676/head:pull/1676 PR: https://git.openjdk.java.net/jdk/pull/1676 From naoto at openjdk.java.net Mon Dec 7 20:43:22 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Dec 2020 20:43:22 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v2] In-Reply-To: References: Message-ID: <2S-J5TsxRWZzizI39a9slJMBMmOpkUJmo2oqWDEc3lc=.f292a8a1-45f5-4317-a241-f4caeb98fe82@github.com> On Mon, 7 Dec 2020 19:30:28 GMT, Brent Christian wrote: >> Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. >> >> The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). >> >> The new version of the test passes 100 times out of 100 on the test farm. > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8200102 > - Use existing ForceGC class in the test lib > - Add gcAwait() mechanism Looks good to me (with trivial nits). test/jdk/java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. Missin 2017? test/jdk/java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java line 72: > 70: if (!gc.await(() -> finalCount == unloadedCount)) { > 71: throw new RuntimeException("Expected unloaded=" + count + > 72: " but got=" + unloadedCount); Could be left unchanged. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1630 From darcy at openjdk.java.net Mon Dec 7 21:20:14 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Dec 2020 21:20:14 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: References: Message-ID: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com> On Mon, 7 Dec 2020 20:08:59 GMT, Jonathan Gibbons wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8257450 >> - Update tests. >> - Merge branch 'master' into JDK-8257450 >> - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 >> - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 >> - JDK-8257450 >> - JDK-8257450 >> - JDK-8257450 > > test/jdk/java/lang/module/ClassFileVersionsTest.java line 107: > >> 105: { 61, 0, Set.of(STATIC, TRANSITIVE) }, >> 106: >> 107: { 62, 0, Set.of()}, // JDK 18 > > This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release? I've had similar thoughts; that strikes me as a fine RFE for after this fork. I see what the code is doing, but haven't delved into the module system details to understand exactly the rationale for these tests. In any case, filed the RFE JDK-8257856: "Make ClassFileVersionsTest.java robust to JDK version updates." ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From darcy at openjdk.java.net Mon Dec 7 21:21:13 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Dec 2020 21:21:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Is there already CSR coverage of this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From hseigel at openjdk.java.net Mon Dec 7 21:33:12 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 7 Dec 2020 21:33:12 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 21:18:45 GMT, Joe Darcy wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Is there already CSR coverage of this change? There is no CSR because I viewed this as a bug fix / spec conformance issue. But, I can write a CSR if you think one is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From lfoltan at openjdk.java.net Mon Dec 7 21:33:11 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 7 Dec 2020 21:33:11 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Changes looks good Harold. Lois src/hotspot/share/prims/jvm.cpp line 2130: > 2128: JvmtiVMObjectAllocEventCollector oam; > 2129: Array* subclasses = ik->permitted_subclasses(); > 2130: int length = subclasses == NULL ? 0 : subclasses->length(); Minor comment - you don't really need the check of subclasses == NULL here since subclasses will never be NULL. You could just assign length to subclasses->length(); ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1675 From mchung at openjdk.java.net Mon Dec 7 21:59:12 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 7 Dec 2020 21:59:12 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: <1kcTuIiOFlvGm3E3_Pig7uvR0fkKTBE5851DyNFLUHg=.1db1e565-eb47-4721-8314-b9ccf5fdd07f@github.com> On Mon, 7 Dec 2020 21:30:18 GMT, Lois Foltan wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Changes looks good Harold. > Lois Hi Harold, > There is no CSR because I viewed this as a bug fix / spec conformance issue. But, I can write a CSR if you think one is needed. This spec change needs a CSR since the return value is changed if this class is not sealed. Please create one. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From darcy at openjdk.java.net Mon Dec 7 22:44:17 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Dec 2020 22:44:17 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:20:58 GMT, Jesper Wilhelmsson wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8257450 >> - Update tests. >> - Merge branch 'master' into JDK-8257450 >> - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 >> - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 >> - JDK-8257450 >> - JDK-8257450 >> - JDK-8257450 > > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 234: > >> 232: * @since 17 >> 233: */ >> 234: RELEASE_17; > > Would it make sense to have a RELEASE_LATEST for the cases that are just updated to the latest release every six months? That kind of design was considered and rejected with the API was initially added. The use of enum constants in annotations must be an actual enum constant, not just a static final field pointing to a particular enum value. It would be possible to conceptually alias RELEASE_LATEST with whatever actual constant was the latest (16, then 17, then 18...), but that would cause issues with other uses of the API. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From bchristi at openjdk.java.net Mon Dec 7 23:37:16 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 7 Dec 2020 23:37:16 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v2] In-Reply-To: <2S-J5TsxRWZzizI39a9slJMBMmOpkUJmo2oqWDEc3lc=.f292a8a1-45f5-4317-a241-f4caeb98fe82@github.com> References: <2S-J5TsxRWZzizI39a9slJMBMmOpkUJmo2oqWDEc3lc=.f292a8a1-45f5-4317-a241-f4caeb98fe82@github.com> Message-ID: On Mon, 7 Dec 2020 20:38:31 GMT, Naoto Sato wrote: >> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8200102 >> - Use existing ForceGC class in the test lib >> - Add gcAwait() mechanism > > test/jdk/java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > Missin 2017? Yes, you're right ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From bchristi at openjdk.java.net Mon Dec 7 23:42:14 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 7 Dec 2020 23:42:14 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v2] In-Reply-To: <2S-J5TsxRWZzizI39a9slJMBMmOpkUJmo2oqWDEc3lc=.f292a8a1-45f5-4317-a241-f4caeb98fe82@github.com> References: <2S-J5TsxRWZzizI39a9slJMBMmOpkUJmo2oqWDEc3lc=.f292a8a1-45f5-4317-a241-f4caeb98fe82@github.com> Message-ID: On Mon, 7 Dec 2020 20:39:34 GMT, Naoto Sato wrote: >> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8200102 >> - Use existing ForceGC class in the test lib >> - Add gcAwait() mechanism > > test/jdk/java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java line 72: > >> 70: if (!gc.await(() -> finalCount == unloadedCount)) { >> 71: throw new RuntimeException("Expected unloaded=" + count + >> 72: " but got=" + unloadedCount); > > Could be left unchanged. True ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From bchristi at openjdk.java.net Mon Dec 7 23:52:29 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 7 Dec 2020 23:52:29 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v3] In-Reply-To: References: Message-ID: <3ykRKumldgGWqcpVehUTiiILoc8_l3fzMWg_8noxyUI=.e47e43aa-129e-4f34-baf8-a22e98017ca5@github.com> > Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. > > The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). > > The new version of the test passes 100 times out of 100 on the test farm. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into 8200102 - Copyright date and indentation cleanup - Merge branch 'master' into 8200102 - Use existing ForceGC class in the test lib - Add gcAwait() mechanism ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1630/files - new: https://git.openjdk.java.net/jdk/pull/1630/files/a6d58148..91814d19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1630&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1630&range=01-02 Stats: 804 lines in 24 files changed: 519 ins; 160 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/1630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1630/head:pull/1630 PR: https://git.openjdk.java.net/jdk/pull/1630 From mchung at openjdk.java.net Tue Dec 8 00:02:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 00:02:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold src/java.base/share/classes/java/lang/Class.java line 4396: > 4394: * is unspecified. If this {@code Class} object represents a primitive type, > 4395: * {@code void}, an array type, or a class or interface that is not sealed, > 4396: * then null is returned. nit: s/null/`{@code null}` I'd suggest to clarify if this sealed class or interface has no permitted subclass, something like this: Returns an array containing {@code Class} objects representing the direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. The order of such elements is unspecified. The array is empty if this sealed class or interface has no permitted subclass. `@return` needs to be revised as well: @return an array of {@code Class} objects of the permitted subclasses of this sealed class or interface, or {@null} if this class or interface is not sealed ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From naoto at openjdk.java.net Tue Dec 8 00:03:15 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Dec 2020 00:03:15 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v3] In-Reply-To: <3ykRKumldgGWqcpVehUTiiILoc8_l3fzMWg_8noxyUI=.e47e43aa-129e-4f34-baf8-a22e98017ca5@github.com> References: <3ykRKumldgGWqcpVehUTiiILoc8_l3fzMWg_8noxyUI=.e47e43aa-129e-4f34-baf8-a22e98017ca5@github.com> Message-ID: On Mon, 7 Dec 2020 23:52:29 GMT, Brent Christian wrote: >> Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. >> >> The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). >> >> The new version of the test passes 100 times out of 100 on the test farm. > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into 8200102 > - Copyright date and indentation cleanup > - Merge branch 'master' into 8200102 > - Use existing ForceGC class in the test lib > - Add gcAwait() mechanism Looks good! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1630 From mchung at openjdk.java.net Tue Dec 8 00:09:15 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 00:09:15 GMT Subject: RFR: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected [v3] In-Reply-To: <3ykRKumldgGWqcpVehUTiiILoc8_l3fzMWg_8noxyUI=.e47e43aa-129e-4f34-baf8-a22e98017ca5@github.com> References: <3ykRKumldgGWqcpVehUTiiILoc8_l3fzMWg_8noxyUI=.e47e43aa-129e-4f34-baf8-a22e98017ca5@github.com> Message-ID: <48dxd1P5m9tqHzxBM6Z9WoTlZduZOnf-rviQdD9efhY=.cf310503-173f-4d87-ac99-16b7e84f6fa8@github.com> On Mon, 7 Dec 2020 23:52:29 GMT, Brent Christian wrote: >> Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. >> >> The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). >> >> The new version of the test passes 100 times out of 100 on the test farm. > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into 8200102 > - Copyright date and indentation cleanup > - Merge branch 'master' into 8200102 > - Use existing ForceGC class in the test lib > - Add gcAwait() mechanism Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From mchung at openjdk.java.net Tue Dec 8 00:16:12 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 00:16:12 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Other changes look okay except the spec of `Class::getPermittedSubclasses` ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From mchung at openjdk.java.net Tue Dec 8 00:16:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 00:16:14 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 21:29:23 GMT, Lois Foltan wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > src/hotspot/share/prims/jvm.cpp line 2130: > >> 2128: JvmtiVMObjectAllocEventCollector oam; >> 2129: Array* subclasses = ik->permitted_subclasses(); >> 2130: int length = subclasses == NULL ? 0 : subclasses->length(); > > Minor comment - you don't really need the check of subclasses == NULL here since subclasses will never be NULL. You could just assign length to subclasses->length(); +1. is_sealed returns true iff `_permitted_subclasses != NULL` ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From smarks at openjdk.java.net Tue Dec 8 00:51:13 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Dec 2020 00:51:13 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message In-Reply-To: References: Message-ID: <7j7UdFeKB6m-L1xarpTVxcUOQZT7Dq5UOFWP6_0hSVA=.229451c0-b846-4d68-b4f6-3937e295f238@github.com> On Mon, 7 Dec 2020 16:05:11 GMT, Roger Riggs wrote: >> The origin of this code is in collections like ArrayList that have an existing array (hence oldLength >= 0) and that need it to grow (hence minGrowth > 0). Those were the prevailing assumptions in the code from which this was derived, so they turn into preconditions here. I don't see the need to try to make this handle any more cases than it currently does. Doing so complicates the analysis and possibly the code as well. Certainly a bug in a caller might be difficult to track down, but I don't want to add argument checking or to provide "reasonable" behavior in the face of unreasonable inputs. This is an internal method; bugs in callers should be fixed. > > The algorithm can be well defined for minGrowth and prefGrowth == 0 without extra checks or exceptions with a careful look at the inequality checks. > For example, as currently coded, if both are zero, it returns SOFT_MAX_ARRAY_LENGTH. > Changing the `0 < prefLength` to `0 <= prefLength` would return minGrowth and avoid a very large but unintentional allocation. That's only true if oldLength is zero. The behavior is different if oldLength is positive. In any case, this method is called when the array needs to **grow**, which means the caller needs to reallocate and copy. If the caller passes zero for both minGrowth and prefGrowth, the caller doesn't need to reallocate and copy, and there's no point in it calling this method in the first place. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From info at j-kuhn.de Tue Dec 8 01:20:35 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 8 Dec 2020 02:20:35 +0100 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive Message-ID: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> Let's start with the reproducer: ??? public class NestmateBug { ??????? private static int field = 0; ??????? public static void main(String[] args) throws Throwable { ??????????? Lookup l = MethodHandles.lookup(); ??????????? Field f = NestmateBug.class.getDeclaredField("field"); ??????????? MethodHandle mh = l.findVirtual(Field.class, "setInt", methodType(void.class, Object.class, int.class)); ??????????? int newValue = 5; ??????????? mh.invokeExact(f, (Object) null, newValue); ??????? } ??? } This throws a IAE in the last line: class test.se15.NestmateBug$$InjectedInvoker/0x0000000800bb5840 (in module test.se15) cannot access a member of class test.se15.NestmateBug (in module test.se15) with modifiers "private static" ?? ?at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385) ?? ?at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:693) ?? ?at java.base/java.lang.reflect.Field.checkAccess(Field.java:1096) ?? ?at java.base/java.lang.reflect.Field.setInt(Field.java:976) ?? ?at test.se15/test.se15.NestmateBug.main(NestmateBug.java:17) The reason for this behaviour is: * Field.setInt (without setAccessible) requires that the caller class is in the same nest for private members. * Field.setInt is @CallerSensitive * MethodHandles will bind to the caller by injecting an invoker for @CallerSensitive methods. * The injected invoker is NOT a nestmate of the original lookup class. * The access check of Field.setInt fails - as the injected invoker is now the caller. This is important because: * Some old software loves to set static final fields through reflection. * To do that, it usually hacks into Field.modifiers. Which is filtered iirc since Java 12. * I write Java agents to fix such things - removing final from static fields, and intercept Class.getDeclaredField and Field.setInt by replacing it with an invokedynamic instruction. * The original target is passed as a MethodHandle bootstrap argument. In the case of Field.setInt, it is guarded with a MethodHandles.guardWithTest() - calling the original target if the Field is not my canary. Suggested fix: * Make the injected invoker a nestmate of lookup class. I did prepare a fix for that [1], but AFAIK the bug first needs to be filled in the bug tracker. And I don't have an account. - Johannes [1]: https://github.com/DasBrain/jdk/commit/3c4bb20c8e4cd9086e934128e5cb085a5cfbdb94 From mchung at openjdk.java.net Tue Dec 8 02:41:18 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 02:41:18 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue Message-ID: `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 ------------- Commit messages: - add suppress warnings - 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue Changes: https://git.openjdk.java.net/jdk/pull/1684/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1684&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8052260 Stats: 28 lines in 2 files changed: 22 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1684/head:pull/1684 PR: https://git.openjdk.java.net/jdk/pull/1684 From mchung at openjdk.java.net Tue Dec 8 02:43:19 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 02:43:19 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> Message-ID: On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Move to share/data, and move jdwp.spec to java.se > > I have reviewed all lines in the patch file with or near instances of `jdk.compiler` Hi Magnus, I see the motivation of moving these build files for better identification of ownership. Placing them under `src/$MODULE/{share,$OS}/data` is one option. Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration?? I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though. Do you see one option is better than the other? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From sundar at openjdk.java.net Tue Dec 8 03:00:34 2020 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Dec 2020 03:00:34 GMT Subject: RFR: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input [v2] In-Reply-To: References: Message-ID: > Safe URI encode logic adopted from UnixUriUtils. Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: renamed the test as per review comment. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1669/files - new: https://git.openjdk.java.net/jdk/pull/1669/files/b3d0a927..4d7417f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1669&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1669&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1669/head:pull/1669 PR: https://git.openjdk.java.net/jdk/pull/1669 From sundar at openjdk.java.net Tue Dec 8 03:00:35 2020 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Dec 2020 03:00:35 GMT Subject: RFR: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:59:40 GMT, Alan Bateman wrote: >> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed the test as per review comment. > > test/jdk/jdk/internal/jrtfs/Test8242258.java line 40: > >> 38: import static org.testng.Assert.assertEquals; >> 39: >> 40: public class Test8242258 { > > I think it would be better to create something like UriTests that we can add further tests for jrtfs URIs as they arise. I'll renamed the test > test/jdk/jdk/internal/jrtfs/Test8242258.java line 60: > >> 58: { "xyz ", "jrt:/xyz%20" }, >> 59: { "xy z", "jrt:/xy%20z" }, >> 60: }; > > One other thing we test here is a malformed escape pair, e.g. "jrt:/%5" and check that getPath(URI) throws IAE. URI.create(String) method itself checks for malformed escape pairs. Do we need anything additional here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1669 From almatvee at openjdk.java.net Tue Dec 8 03:12:11 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 8 Dec 2020 03:12:11 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:29:56 GMT, Andy Herrick wrote: > increase retries and timeout increasing in runMsiexecWithRetries Looks like test failed due to: [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity. So, I am not sure how increased repeat will help. Do we know why it failed to parse XML? ------------- PR: https://git.openjdk.java.net/jdk/pull/1676 From darcy at openjdk.java.net Tue Dec 8 03:24:20 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 03:24:20 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v17] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:13:21 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/util/HexFormat.java line 936: >> >>> 934: * if any of the characters is not a hexadecimal character >>> 935: */ >>> 936: public int fromHexDigits(CharSequence string) { >> >> I recommend this group of methods include an apinote explaining the differences in behavior of compared to parseInt(s, 16) and parseUnsignedInt(s, 16). > > Will add: > * @apiNote > * {@link Integer#parseInt(String, int) Integer.parseInt(s, 16)} and > * {@link Integer#parseUnsignedInt(String, int) Integer.pareUnsignedInt(s, 16)} > * are similar but allow all Unicode hexadecimal digits allowed by > * {@link Character#digit(char, int) Character.digit(ch, 16)}. > * {@code HexFormat} uses only Latin1 hexadecimal characters "0-9, "A-F", and "a-f". > * {@link Integer#parseInt(String, int)} can parse signed hexadecimal strings. > And similar text for Long#parseLong and Long.parseUnsignedLong Okay; however, I suggest saying more on the signed/unsigned behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From darcy at openjdk.java.net Tue Dec 8 03:33:31 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 03:33:31 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v3] In-Reply-To: References: Message-ID: > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - JDK-8257450 - JDK-8257450 - JDK-8257450 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/f6a64473..96e75b08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=01-02 Stats: 851 lines in 29 files changed: 560 ins; 163 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From david.holmes at oracle.com Tue Dec 8 04:13:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2020 14:13:52 +1000 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> Message-ID: <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> Hi Johannes, I've filed this bug report for you: https://bugs.openjdk.java.net/browse/JDK-8257874 Thanks, David On 8/12/2020 11:20 am, Johannes Kuhn wrote: > Let's start with the reproducer: > > ??? public class NestmateBug { > ??????? private static int field = 0; > ??????? public static void main(String[] args) throws Throwable { > ??????????? Lookup l = MethodHandles.lookup(); > ??????????? Field f = NestmateBug.class.getDeclaredField("field"); > ??????????? MethodHandle mh = l.findVirtual(Field.class, "setInt", > methodType(void.class, Object.class, int.class)); > ??????????? int newValue = 5; > ??????????? mh.invokeExact(f, (Object) null, newValue); > ??????? } > ??? } > > This throws a IAE in the last line: > > class test.se15.NestmateBug$$InjectedInvoker/0x0000000800bb5840 (in > module test.se15) cannot access a member of class test.se15.NestmateBug > (in module test.se15) with modifiers "private static" > ?? ?at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385) > > ?? ?at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:693) > > ?? ?at java.base/java.lang.reflect.Field.checkAccess(Field.java:1096) > ?? ?at java.base/java.lang.reflect.Field.setInt(Field.java:976) > ?? ?at test.se15/test.se15.NestmateBug.main(NestmateBug.java:17) > > The reason for this behaviour is: > * Field.setInt (without setAccessible) requires that the caller class is > in the same nest for private members. > * Field.setInt is @CallerSensitive > * MethodHandles will bind to the caller by injecting an invoker for > @CallerSensitive methods. > * The injected invoker is NOT a nestmate of the original lookup class. > * The access check of Field.setInt fails - as the injected invoker is > now the caller. > > This is important because: > * Some old software loves to set static final fields through reflection. > * To do that, it usually hacks into Field.modifiers. Which is filtered > iirc since Java 12. > * I write Java agents to fix such things - removing final from static > fields, and intercept Class.getDeclaredField and Field.setInt by > replacing it with an invokedynamic instruction. > * The original target is passed as a MethodHandle bootstrap argument. In > the case of Field.setInt, it is guarded with a > MethodHandles.guardWithTest() - calling the original target if the Field > is not my canary. > > Suggested fix: > * Make the injected invoker a nestmate of lookup class. > > I did prepare a fix for that [1], but AFAIK the bug first needs to be > filled in the bug tracker. > And I don't have an account. > > - Johannes > > > [1]: > https://github.com/DasBrain/jdk/commit/3c4bb20c8e4cd9086e934128e5cb085a5cfbdb94 From mandy.chung at oracle.com Tue Dec 8 04:40:56 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Dec 2020 20:40:56 -0800 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> Message-ID: <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> Thanks David.? I was about to create one. This is indeed a gap in injecting this trampoline class for supporting @CallerSensitive methods.? The InjectedInvoker ensures that the InjectedInvoker class has the same class loader as the lookup class.? W.r.t. your patch, it seems okay but I have to consider and think through the security implication carefully. You mentioned "Some old software loves to set static final fields through reflection" - can you share some example libraries about this??? This is really ugly hack!! Mandy On 12/7/20 8:13 PM, David Holmes wrote: > Hi Johannes, > > I've filed this bug report for you: > > https://bugs.openjdk.java.net/browse/JDK-8257874 > > Thanks, > David > > On 8/12/2020 11:20 am, Johannes Kuhn wrote: >> Let's start with the reproducer: >> >> ???? public class NestmateBug { >> ???????? private static int field = 0; >> ???????? public static void main(String[] args) throws Throwable { >> ???????????? Lookup l = MethodHandles.lookup(); >> ???????????? Field f = NestmateBug.class.getDeclaredField("field"); >> ???????????? MethodHandle mh = l.findVirtual(Field.class, "setInt", >> methodType(void.class, Object.class, int.class)); >> ???????????? int newValue = 5; >> ???????????? mh.invokeExact(f, (Object) null, newValue); >> ???????? } >> ???? } >> >> This throws a IAE in the last line: >> >> class test.se15.NestmateBug$$InjectedInvoker/0x0000000800bb5840 (in >> module test.se15) cannot access a member of class >> test.se15.NestmateBug (in module test.se15) with modifiers "private >> static" >> ??? ?at >> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385) >> >> ??? ?at >> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:693) >> >> ??? ?at java.base/java.lang.reflect.Field.checkAccess(Field.java:1096) >> ??? ?at java.base/java.lang.reflect.Field.setInt(Field.java:976) >> ??? ?at test.se15/test.se15.NestmateBug.main(NestmateBug.java:17) >> >> The reason for this behaviour is: >> * Field.setInt (without setAccessible) requires that the caller class >> is in the same nest for private members. >> * Field.setInt is @CallerSensitive >> * MethodHandles will bind to the caller by injecting an invoker for >> @CallerSensitive methods. >> * The injected invoker is NOT a nestmate of the original lookup class. >> * The access check of Field.setInt fails - as the injected invoker is >> now the caller. >> >> This is important because: >> * Some old software loves to set static final fields through reflection. >> * To do that, it usually hacks into Field.modifiers. Which is >> filtered iirc since Java 12. >> * I write Java agents to fix such things - removing final from static >> fields, and intercept Class.getDeclaredField and Field.setInt by >> replacing it with an invokedynamic instruction. >> * The original target is passed as a MethodHandle bootstrap argument. >> In the case of Field.setInt, it is guarded with a >> MethodHandles.guardWithTest() - calling the original target if the >> Field is not my canary. >> >> Suggested fix: >> * Make the injected invoker a nestmate of lookup class. >> >> I did prepare a fix for that [1], but AFAIK the bug first needs to be >> filled in the bug tracker. >> And I don't have an account. >> >> - Johannes >> >> >> [1]: >> https://github.com/DasBrain/jdk/commit/3c4bb20c8e4cd9086e934128e5cb085a5cfbdb94 From kbarrett at openjdk.java.net Tue Dec 8 05:04:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 05:04:13 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 02:36:01 GMT, Mandy Chung wrote: > `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. > > This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 This change looks good. There are a couple of tests that are using isEnqueued. vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java jdk/java/lang/ref/ReferenceEnqueue.java https://bugs.openjdk.java.net/browse/JDK-8257876 (I'm working on this.) ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1684 From martin at openjdk.java.net Tue Dec 8 05:07:21 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 05:07:21 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 Message-ID: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 ------------- Commit messages: - JDK-8234131 Changes: https://git.openjdk.java.net/jdk/pull/1647/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1647&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234131 Stats: 314 lines in 41 files changed: 107 ins; 41 del; 166 mod Patch: https://git.openjdk.java.net/jdk/pull/1647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1647/head:pull/1647 PR: https://git.openjdk.java.net/jdk/pull/1647 From mchung at openjdk.java.net Tue Dec 8 05:08:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 05:08:14 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 05:01:08 GMT, Kim Barrett wrote: >> `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. >> >> This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 > > This change looks good. There are a couple of tests that are using isEnqueued. > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > jdk/java/lang/ref/ReferenceEnqueue.java > https://bugs.openjdk.java.net/browse/JDK-8257876 > (I'm working on this.) Thanks, Kim. It's good to update the tests (thanks for working on it). ------------- PR: https://git.openjdk.java.net/jdk/pull/1684 From martin at openjdk.java.net Tue Dec 8 05:08:20 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 05:08:20 GMT Subject: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates Message-ID: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates ------------- Commit messages: - JDK-8246677 Changes: https://git.openjdk.java.net/jdk/pull/1645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1645&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246677 Stats: 538 lines in 3 files changed: 143 ins; 294 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/1645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1645/head:pull/1645 PR: https://git.openjdk.java.net/jdk/pull/1645 From martin at openjdk.java.net Tue Dec 8 05:09:19 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 05:09:19 GMT Subject: RFR: 8246585: ForkJoin updates Message-ID: 8246585: ForkJoin updates ------------- Commit messages: - JDK-8246585 Changes: https://git.openjdk.java.net/jdk/pull/1646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246585 Stats: 3114 lines in 6 files changed: 1135 ins; 890 del; 1089 mod Patch: https://git.openjdk.java.net/jdk/pull/1646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1646/head:pull/1646 PR: https://git.openjdk.java.net/jdk/pull/1646 From martin at openjdk.java.net Tue Dec 8 05:10:26 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 05:10:26 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException Message-ID: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> 8254350: CompletableFuture.get may swallow InterruptedException ------------- Commit messages: - JDK-8254350 Changes: https://git.openjdk.java.net/jdk/pull/1651/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1651&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254350 Stats: 178 lines in 3 files changed: 170 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1651/head:pull/1651 PR: https://git.openjdk.java.net/jdk/pull/1651 From minqi at openjdk.java.net Tue Dec 8 05:45:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 8 Dec 2020 05:45:20 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. > The fix is the first step of two steps: > 1) Do not split reserved memory; > 2) Remove splitting memory. > This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request incrementally with 32 additional commits since the last revision: - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test. - 8253762: JFR: getField(String) should be able to access subfields Reviewed-by: mgronlun - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks Reviewed-by: jnimeh - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32 Reviewed-by: kvn - 8257211: C2: Enable call devirtualization during post-parse phase Reviewed-by: kvn, neliasso, thartmann - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Reviewed-by: ihse, alanb, dcubed, erikj - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs Reviewed-by: redestad, kvn - 8257799: Update JLS cross-references in java.compiler Reviewed-by: jjg - 8254939: macOS: unused function 'replicate4_imm' Reviewed-by: redestad, thartmann - 8257805: Add compiler/blackhole tests to tier1 Reviewed-by: kvn - ... and 22 more: https://git.openjdk.java.net/jdk/compare/dd9ae050...f7958306 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1657/files - new: https://git.openjdk.java.net/jdk/pull/1657/files/dd9ae050..f7958306 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=01-02 Stats: 8052 lines in 156 files changed: 4548 ins; 2755 del; 749 mod Patch: https://git.openjdk.java.net/jdk/pull/1657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657 PR: https://git.openjdk.java.net/jdk/pull/1657 From martin at openjdk.java.net Tue Dec 8 05:54:24 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 05:54:24 GMT Subject: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates [v2] In-Reply-To: References: Message-ID: > 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8246677 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1645/files - new: https://git.openjdk.java.net/jdk/pull/1645/files/13eb0fa8..b8baa921 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1645&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1645&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1645/head:pull/1645 PR: https://git.openjdk.java.net/jdk/pull/1645 From martin at openjdk.java.net Tue Dec 8 06:04:28 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 06:04:28 GMT Subject: RFR: 8246585: ForkJoin updates [v2] In-Reply-To: References: Message-ID: > 8246585: ForkJoin updates Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8246585 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1646/files - new: https://git.openjdk.java.net/jdk/pull/1646/files/0ae46847..d025f68b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1646&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1646&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1646/head:pull/1646 PR: https://git.openjdk.java.net/jdk/pull/1646 From martin at openjdk.java.net Tue Dec 8 06:11:27 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 06:11:27 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2] In-Reply-To: References: Message-ID: > 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8234131 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1647/files - new: https://git.openjdk.java.net/jdk/pull/1647/files/ed43b3fe..a6d85863 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1647&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1647&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1647/head:pull/1647 PR: https://git.openjdk.java.net/jdk/pull/1647 From darcy at openjdk.java.net Tue Dec 8 06:12:35 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 06:12:35 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v4] In-Reply-To: References: Message-ID: > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - JDK-8257450 - JDK-8257450 - JDK-8257450 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/96e75b08..342c8650 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From stuart.marks at oracle.com Tue Dec 8 06:13:14 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 7 Dec 2020 22:13:14 -0800 Subject: MatchResult support for named groups In-Reply-To: References: <14517.1606845585151306433@groups.io> Message-ID: OK, thanks, good information. Clearly support for named groups is the most important thing missing from MatchResult. s'marks On 12/4/20 11:43 PM, Cay Horstmann wrote: > Hi Stuart, > > 1: If there is no match at all, then results yields the empty stream. I don't think > anything else is required. > > 2/3: I wrote a fair number of regex patterns in Java, ever since they appeared in > 2002. I can say with confidence that I never once used hitEnd/requireEnd, or seen it > used. I note they occur in one file in the JDK 11 source, in the Scanner class. But > not in a loop that fetches all matches, but after a single call to find or > lookingAt. I think these are exceedingly uncommon. > > In contrast, looping over matcher.find() and extracting groups is common, and named > groups are a best practice > (https://urldefense.com/v3/__https://eslint.org/docs/rules/prefer-named-capture-group__;!!GqivPVa7Brio!I3YBH6KonWfqm4zW7pQRatPsLcj4rRjGOveB6NWQedZVU8BeJ3hknZcPy7rC1G2fug$ > ). > > Cheers, > > Cay > > Il 04/12/2020 19:53, Stuart Marks ha scritto: >> Hi Cay, >> >> Thanks for mentioning this. It's good to know that adding this provides value to >> people who are actually trying to use this stuff (as opposed to adding stuff >> merely for the sake of completeness, as often seems to arise). >> >> I've added some notes to JDK-8065554. >> >> Looking at this more closely, it seems to me that MatchResult ought to include >> more match-result-related information that's currently only in Matcher, namely: >> >> 1. whether there was a match at all >> 2. hitEnd >> 3. requireEnd >> >> If you have any thoughts on these, please let me know. >> >> s'marks >> >> On 12/2/20 2:53 AM, Cay Horstmann wrote: >>> Hello, I'd like to raise awareness for >>> >>> https://bugs.openjdk.java.net/browse/JDK-8180352 >>> https://bugs.openjdk.java.net/browse/JDK-8072984 >>> https://bugs.openjdk.java.net/browse/JDK-8065554 >>> >>> These all ask for MatchResult.group(String name). What they don't mention is that >>> this is more urgent in light of the methods >>> >>> Stream Matcher.results() // >>> https://bugs.openjdk.java.net/browse/JDK-8071479 >>> Stream Scanner.findAll(Pattern pattern) // >>> https://bugs.openjdk.java.net/browse/JDK-8072722 >>> >>> In particular, Matcher.results() seems a cleaner way of collecting match results >>> than calling while (matcher.find()). >>> >>> But then MatchResult needs to support the same queries that Matcher provides. I >>> believe the only missing one is group(String name). >>> >>> Cheers, >>> >>> Cay >>> >>> NB. There are related requests that ask for finding group names in patterns, or >>> for correlating group names and numbers. I have formed no opinion on their merits. >>> > From smarks at openjdk.java.net Tue Dec 8 06:14:35 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Dec 2020 06:14:35 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v2] In-Reply-To: References: Message-ID: > This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: > > 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! > > 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. > > Separately, I'll work on retrofitting various call sites around the JDK to use this method. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: fix typo, clarify asserts disabled, test prefGrowth==0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1617/files - new: https://git.openjdk.java.net/jdk/pull/1617/files/03b7922f..bacb5f91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=00-01 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1617/head:pull/1617 PR: https://git.openjdk.java.net/jdk/pull/1617 From martin at openjdk.java.net Tue Dec 8 06:30:28 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 06:30:28 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: > 8254350: CompletableFuture.get may swallow InterruptedException Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8254350 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1651/files - new: https://git.openjdk.java.net/jdk/pull/1651/files/4e32f8c1..762a1715 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1651&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1651&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1651/head:pull/1651 PR: https://git.openjdk.java.net/jdk/pull/1651 From alanb at openjdk.java.net Tue Dec 8 07:48:13 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 07:48:13 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v2] In-Reply-To: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com> References: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com> Message-ID: On Mon, 7 Dec 2020 21:14:55 GMT, Joe Darcy wrote: >> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107: >> >>> 105: { 61, 0, Set.of(STATIC, TRANSITIVE) }, >>> 106: >>> 107: { 62, 0, Set.of()}, // JDK 18 >> >> This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release? > > I've had similar thoughts; that strikes me as a fine RFE for after this fork. I see what the code is doing, but haven't delved into the module system details to understand exactly the rationale for these tests. In any case, filed the RFE JDK-8257856: "Make ClassFileVersionsTest.java robust to JDK version updates." There was a change to JVMS 4.7.25 in Java 10 to add a rule for the requires_flags that are allowed. This is why this test started was created to test 53.0 vs. 54.0 class files. It wasn't intended to be a burden to update at each release so I'll re-implement it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From alanb at openjdk.java.net Tue Dec 8 07:53:13 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 07:53:13 GMT Subject: RFR: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 03:00:34 GMT, Athijegannathan Sundararajan wrote: >> Safe URI encode logic adopted from UnixUriUtils. > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > renamed the test as per review comment. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1669 From alanb at openjdk.java.net Tue Dec 8 07:53:15 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 07:53:15 GMT Subject: RFR: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input [v2] In-Reply-To: References: Message-ID: <343KhtKSDOCRsFoifNpbHyqH_YJkifj6YnHuLuXF9ZY=.1b70ae31-95f2-46ff-ab09-22876da73cee@github.com> On Tue, 8 Dec 2020 02:55:43 GMT, Athijegannathan Sundararajan wrote: >> test/jdk/jdk/internal/jrtfs/Test8242258.java line 60: >> >>> 58: { "xyz ", "jrt:/xyz%20" }, >>> 59: { "xy z", "jrt:/xy%20z" }, >>> 60: }; >> >> One other thing we test here is a malformed escape pair, e.g. "jrt:/%5" and check that getPath(URI) throws IAE. > > URI.create(String) method itself checks for malformed escape pairs. Do we need anything additional here? The bug report is Path -> URI but any testing here has to do round-trip (as you have done). My comment about the malformed escaped pair is that we don't seem to have tests for this case, or did I missed it? The example I tased was %5 which isn't a complete pair and will be rejected. In any case, I think what you have is fine for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1669 From alanb at openjdk.java.net Tue Dec 8 07:56:13 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 07:56:13 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Tue, 8 Dec 2020 06:30:28 GMT, Martin Buchholz wrote: >> 8254350: CompletableFuture.get may swallow InterruptedException > > Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8254350 Marked as reviewed by alanb (Reviewer). test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java line 37: > 35: */ > 36: > 37: // TODO: Rewrite as a CompletableFuture tck test ? Do you want the "TODO" in the commit? ------------- PR: https://git.openjdk.java.net/jdk/pull/1651 From shade at openjdk.java.net Tue Dec 8 08:05:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 08:05:11 GMT Subject: RFR: 8246585: ForkJoin updates In-Reply-To: References: Message-ID: On Sun, 6 Dec 2020 02:56:34 GMT, Martin Buchholz wrote: > 8246585: ForkJoin updates It would be nice to get it tested with GH Actions. "Checks" tabs should have those testing results automatically on push, but it is empty. Probably because your fork is not configured for it. Please go to https://github.com/Martin-Buchholz/jdk/actions -- and see if it says anything suspicious? Triggering the (only) workflow manually against your branch would help too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1646 From shade at openjdk.java.net Tue Dec 8 08:05:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 08:05:11 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 In-Reply-To: References: Message-ID: On Sun, 6 Dec 2020 02:57:03 GMT, Martin Buchholz wrote: > 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 It would be nice to get it tested with GH Actions. "Checks" tabs should have those testing results automatically on push, but it is empty. Probably because your fork is not configured for it. Please go to https://github.com/Martin-Buchholz/jdk/actions -- and see if it says anything suspicious? Triggering the (only) workflow manually against your branch would help too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From shade at openjdk.java.net Tue Dec 8 08:12:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 08:12:14 GMT Subject: RFR: 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary In-Reply-To: References: Message-ID: <04_C972j9Hi495dnPYFMKRiEG7Uhvb6p350BmhEOSQE=.eed3d72b-4a63-4f34-8177-fac7286056c2@github.com> On Mon, 7 Dec 2020 17:38:40 GMT, Maurizio Cimadamore wrote: > This simple patch updates the jaavdoc in the module-info file of jdk.incubator.foreign to reflect the fact that support of foreign function calls has been added. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1671 From ihse at openjdk.java.net Tue Dec 8 08:30:12 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 8 Dec 2020 08:30:12 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> Message-ID: On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote: >> I have reviewed all lines in the patch file with or near instances of `jdk.compiler` > > Hi Magnus, > > I see the motivation of moving these build files for better identification of ownership. Placing them under > `src/$MODULE/{share,$OS}/data` is one option. Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration?? I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though. Do you see one option is better than the other? @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`! This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`; or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Dec 8 08:35:13 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 8 Dec 2020 08:35:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> Message-ID: On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie wrote: >> Hi Magnus, >> >> I see the motivation of moving these build files for better identification of ownership. Placing them under >> `src/$MODULE/{share,$OS}/data` is one option. Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration?? I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though. Do you see one option is better than the other? > > @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`! > > This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`; or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter. Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From alanb at openjdk.java.net Tue Dec 8 08:56:15 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 08:56:15 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 06:11:27 GMT, Martin Buchholz wrote: >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 1560: > 1558: break; > 1559: } > 1560: */ Is this meant to be commented out? ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From shade at openjdk.java.net Tue Dec 8 09:00:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 09:00:18 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 Message-ID: See here: https://github.com/mcimadamore/jdk/runs/1460615378 $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java STDERR: Invalid maximum heap size: -Xmx4G The specified size exceeds the maximum representable size. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. Additional testing: - [x] Affected test on Linux x86_32 (skipped now) - [x] Affected test on Linux x86_64 (still passes) ------------- Commit messages: - 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 Changes: https://git.openjdk.java.net/jdk/pull/1688/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1688&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257887 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1688.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1688/head:pull/1688 PR: https://git.openjdk.java.net/jdk/pull/1688 From jiefu at openjdk.java.net Tue Dec 8 09:03:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 09:03:17 GMT Subject: RFR: 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 Message-ID: Hi all, java/foreign/TestSegments.java fails on x86_32 due to '-Xmx4G'. The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. The current implimentation only supports maximum 3800M on 32-bit systems [1]. The fix just change '-Xmx4G' to '-Xmx3500M'. Testing: - java/foreign/TestSegments.java on Linux/x86_{32,64} Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 ------------- Commit messages: - 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 Changes: https://git.openjdk.java.net/jdk/pull/1689/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1689&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257885 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1689.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1689/head:pull/1689 PR: https://git.openjdk.java.net/jdk/pull/1689 From shade at openjdk.java.net Tue Dec 8 09:10:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 09:10:11 GMT Subject: RFR: 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:59:25 GMT, Jie Fu wrote: > Hi all, > > java/foreign/TestSegments.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implimentation only supports maximum 3800M on 32-bit systems [1]. > > The fix just change '-Xmx4G' to '-Xmx3500M'. > > Testing: > - java/foreign/TestSegments.java on Linux/x86_{32,64} > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 `-Xm3800M` could still fail on many 32-bit systems, for example where native libraries are located in the middle of address space. I think it is safer to `@require` it. In fact, I did it an hour ago here #1688 :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1689 From jiefu at openjdk.java.net Tue Dec 8 09:25:11 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 09:25:11 GMT Subject: RFR: 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:07:27 GMT, Aleksey Shipilev wrote: > `-Xm3800M` could still fail on many 32-bit systems, for example where native libraries are located in the middle of address space. I think it is safer to `@require` it. In fact, I did it an hour ago here #1688 :) The test just limits the maximum memory to be used, not the minimum memory. So I think the foreign api should also work on 32-bit platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/1689 From chegar at openjdk.java.net Tue Dec 8 09:34:16 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 8 Dec 2020 09:34:16 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: <0gY9SoxDO9oyPxcbLEKGp2Nv9JI1QTtk8OvCAqKvdtM=.51219b79-aa76-4e2d-bf93-0178a6f2e9b1@github.com> On Mon, 7 Dec 2020 23:47:40 GMT, Mandy Chung wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > src/java.base/share/classes/java/lang/Class.java line 4396: > >> 4394: * is unspecified. If this {@code Class} object represents a primitive type, >> 4395: * {@code void}, an array type, or a class or interface that is not sealed, >> 4396: * then null is returned. > > nit: s/null/`{@code null}` > > I'd suggest to clarify if this sealed class or interface has no permitted subclass, something like this: > Returns an array containing {@code Class} objects representing the > direct subinterfaces or subclasses permitted to extend or > implement this class or interface if it is sealed. The order of such elements > is unspecified. The array is empty if this sealed class or interface has no > permitted subclass. > > `@return` needs to be revised as well: > @return an array of {@code Class} objects of the permitted subclasses of this sealed class or interface, > or {@null} if this class or interface is not sealed Mandy's suggested wording is good. I would like to add one more additional point of clarification. It would be good to strongly connect `isSealed` and `getPermittedClasses` in a first-class way in normative spec ( similar to isRecord and getRecordComponents ). For example, to `isSealed` add: "getPermittedSubclasses returns a non-null but possibly empty value for a sealed class." to `getPermittedSubclasses`: "If this class is not a sealed class, that is {@link * #isSealed()} returns {@code false}, then this method returns {@code null}. * Conversely, if {@link #isSealed()} returns {@code true}, then this method * returns a non-null value." ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From jiefu at openjdk.java.net Tue Dec 8 09:36:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 09:36:13 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:54:41 GMT, Aleksey Shipilev wrote: > See here: > https://github.com/mcimadamore/jdk/runs/1460615378 > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java > > STDERR: > Invalid maximum heap size: -Xmx4G > The specified size exceeds the maximum representable size. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. > > Additional testing: > - [x] Affected test on Linux x86_32 (skipped now) > - [x] Affected test on Linux x86_64 (still passes) The original test doesn't seem to be designed for 64-bit platforms only. So it may not a good idea to skip it for 32-bit platforms. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From sundar at openjdk.java.net Tue Dec 8 09:42:14 2020 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Dec 2020 09:42:14 GMT Subject: Integrated: 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 16:35:52 GMT, Athijegannathan Sundararajan wrote: > Safe URI encode logic adopted from UnixUriUtils. This pull request has now been integrated. Changeset: d2b66196 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/d2b66196 Stats: 218 lines in 2 files changed: 206 ins; 5 del; 7 mod 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1669 From kbarrett at openjdk.java.net Tue Dec 8 10:13:18 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 10:13:18 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests Message-ID: Please review this change that eliminates the use of Reference.isEnqueued by tests. There were three tests using it: vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java jdk/java/lang/ref/ReferenceEnqueue.java In each of them, some combination of using Reference.refersTo and ReferenceQueue.remove with a timeout were used to eliminate the use of Reference.isEnqueued. I also cleaned up ReferencesGC.java in various respects. It contained several bits of dead code, and the failure checks were made stronger. Testing: mach5 tier1 Locally (linux-x64) ran all three tests with each GC (including Shenandoah). ------------- Commit messages: - update WeakReferenceGC test - update ReferenceQueue test - update ReferencesGC test Changes: https://git.openjdk.java.net/jdk/pull/1691/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1691&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257876 Stats: 102 lines in 3 files changed: 21 ins; 39 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/1691.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1691/head:pull/1691 PR: https://git.openjdk.java.net/jdk/pull/1691 From shade at openjdk.java.net Tue Dec 8 10:20:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 10:20:18 GMT Subject: RFR: 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:22:05 GMT, Jie Fu wrote: > > `-Xm3800M` could still fail on many 32-bit systems, for example where native libraries are located in the middle of address space. I think it is safer to `@require` it. In fact, I did it an hour ago here #1688 :) > > The test just limits the maximum memory to be used, not the minimum memory. > So I think the foreign api should also work on 32-bit platforms. Well, I think the test still fails with your fix: https://github.com/DamonFool/jdk/runs/1516430124 -- as I suspected it would :( ------------- PR: https://git.openjdk.java.net/jdk/pull/1689 From dfuchs at openjdk.java.net Tue Dec 8 10:22:15 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Dec 2020 10:22:15 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Tue, 8 Dec 2020 06:30:28 GMT, Martin Buchholz wrote: >> 8254350: CompletableFuture.get may swallow InterruptedException > > Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java line 49: > 47: > 48: public static void main(String[] args) throws Exception { > 49: ThreadLocalRandom rnd = ThreadLocalRandom.current(); Hi Martin, Is using a `ThreadLocalRandom` important for the test logic? I was wondering whether it would be better to use ( `* @library /test/lib`) `jdk.test.lib.RandomFactory`, which prints the random seed in the output so that you can reproduce with the same pseudo-random sequence in case of test failures. best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/1651 From alanb at openjdk.java.net Tue Dec 8 10:38:16 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 10:38:16 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Tue, 8 Dec 2020 10:19:22 GMT, Daniel Fuchs wrote: >> Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java line 49: > >> 47: >> 48: public static void main(String[] args) throws Exception { >> 49: ThreadLocalRandom rnd = ThreadLocalRandom.current(); > > Hi Martin, > > Is using a `ThreadLocalRandom` important for the test logic? > I was wondering whether it would be better to use ( `* @library /test/lib`) `jdk.test.lib.RandomFactory`, > which prints the random seed in the output so that you can reproduce with the same pseudo-random > sequence in case of test failures. > > best regards, > > -- daniel RandomFactory is probably overkill here as the test just needs to exercise untimed and timed get. So just a random boolean rather than a wide range of random values. ------------- PR: https://git.openjdk.java.net/jdk/pull/1651 From jboes at openjdk.java.net Tue Dec 8 10:44:14 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 8 Dec 2020 10:44:14 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record In-Reply-To: References: Message-ID: <_LEx3RcGeEkkpCx-FSXwYFQWb8iY5rylfCwcRA-VT3Q=.8a146e10-8c58-465a-b130-0dcf269b2244@github.com> On Mon, 7 Dec 2020 18:22:33 GMT, Daniel Fuchs wrote: >> This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. >> >> The following rules were applied: >> - 'class' and/or 'interface' are used when referring to the class/interface itself >> - 'type' is used when referring to the type of a variable or expression > > src/java.base/share/classes/java/lang/Enum.java line 62: > >> 60: * java.util.EnumMap map} implementations are available. >> 61: * >> 62: * @param The enum class subclass > > I wonder about this one, given that `` is a type. It sounds strange to me - even though I understand that what is meant is that this type should point to a class (a subclass of `java.lang.Enum`). Makes sense. I suggest the following instead: `The type of enum subclass`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1670 From jiefu at openjdk.java.net Tue Dec 8 10:52:18 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 10:52:18 GMT Subject: RFR: 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 In-Reply-To: References: Message-ID: <4VlUwp8gzSIc74Fvk5xrzEbX4120gyX-nTGZ0fGP5lU=.984bea07-54bc-4d0b-aa49-370ee8431583@github.com> On Tue, 8 Dec 2020 10:17:48 GMT, Aleksey Shipilev wrote: > > > `-Xm3800M` could still fail on many 32-bit systems, for example where native libraries are located in the middle of address space. I think it is safer to `@require` it. In fact, I did it an hour ago here #1688 :) > > > > > > The test just limits the maximum memory to be used, not the minimum memory. > > So I think the foreign api should also work on 32-bit platforms. > > Well, I think the test still fails with your fix: https://github.com/DamonFool/jdk/runs/1516430124 -- as I suspected it would :( OK. It seems the test is brittle on 32-bit platforms. I agree with you now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1689 From jiefu at openjdk.java.net Tue Dec 8 10:55:10 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 10:55:10 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: <5qW417-Ie3WzHkrztKPWXyRLpZVP0IcJysOgQx8pBDs=.ab4e7b80-6344-4f21-bfd7-fae541ea3f51@github.com> On Tue, 8 Dec 2020 08:54:41 GMT, Aleksey Shipilev wrote: > See here: > https://github.com/mcimadamore/jdk/runs/1460615378 > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java > > STDERR: > Invalid maximum heap size: -Xmx4G > The specified size exceeds the maximum representable size. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. > > Additional testing: > - [x] Affected test on Linux x86_32 (skipped now) > - [x] Affected test on Linux x86_64 (still passes) The test is brittle on 32-bit platforms (see https://github.com/openjdk/jdk/pull/1689 ). I agree with @shipilev . ------------- Marked as reviewed by jiefu (Committer). PR: https://git.openjdk.java.net/jdk/pull/1688 From jiefu at openjdk.java.net Tue Dec 8 10:59:12 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 10:59:12 GMT Subject: Withdrawn: 8257885: [TESTBUG] java/foreign/TestSegments.java fails on x86_32 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:59:25 GMT, Jie Fu wrote: > Hi all, > > java/foreign/TestSegments.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implimentation only supports maximum 3800M on 32-bit systems [1]. > > The fix just change '-Xmx4G' to '-Xmx3500M'. > > Testing: > - java/foreign/TestSegments.java on Linux/x86_{32,64} > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1689 From sspitsyn at openjdk.java.net Tue Dec 8 11:46:36 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 8 Dec 2020 11:46:36 GMT Subject: RFR: 8165276: Spec states that invoke the premain method in an agent =?UTF-8?B?Y2zigKY=?= Message-ID: This change have been already reviewed by Mandy, Alan and David. Now, the PR approval is needed. The push was postponed because the CSR was not approved at that time (it is now): https://bugs.openjdk.java.net/browse/JDK-8248189 Investigation of existing popular java agents was requested by Joe. ---------- The java.lang.instrument spec: https://docs.oracle.com/en/java/javase/15/docs/api/java.instrument/java/lang/instrument/package-summary.html Summary: The java.lang.instrument spec clearly states: "The agent class must implement a public static premain method similar in principle to the main application entry point." Current implementation of sun/instrument/InstrumentationImpl.java allows the premain method be non-public which violates the spec. This fix aligns the implementation with the spec. Testing: A mach5 run of jdk_instrument tests is in progress. ------------- Commit messages: - JDK-8165276 Spec states that invoke the premain method in an agent class if it's public but implementation differs Changes: https://git.openjdk.java.net/jdk/pull/1694/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1694&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8165276 Stats: 356 lines in 26 files changed: 251 ins; 56 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/1694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1694/head:pull/1694 PR: https://git.openjdk.java.net/jdk/pull/1694 From dfuchs at openjdk.java.net Tue Dec 8 11:54:16 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Dec 2020 11:54:16 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Tue, 8 Dec 2020 10:35:20 GMT, Alan Bateman wrote: >> test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java line 49: >> >>> 47: >>> 48: public static void main(String[] args) throws Exception { >>> 49: ThreadLocalRandom rnd = ThreadLocalRandom.current(); >> >> Hi Martin, >> >> Is using a `ThreadLocalRandom` important for the test logic? >> I was wondering whether it would be better to use ( `* @library /test/lib`) `jdk.test.lib.RandomFactory`, >> which prints the random seed in the output so that you can reproduce with the same pseudo-random >> sequence in case of test failures. >> >> best regards, >> >> -- daniel > > RandomFactory is probably overkill here as the test just needs to exercise untimed and timed get. So just a random boolean rather than a wide range of random values. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/1651 From prappo at openjdk.java.net Tue Dec 8 11:54:18 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 8 Dec 2020 11:54:18 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:53:38 GMT, Alan Bateman wrote: >> Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 1560: > >> 1558: break; >> 1559: } >> 1560: */ > > Is this meant to be commented out? This code was also commented out in the original CVS repo; here's the diff: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.193&r2=1.194 The message for the `1.194` revision suggests we should NOT expect code changes. I've double-checked my patch, which is at least partially responsible for the `1.194` revision, and couldn't find that commenting out part. ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From dl at cs.oswego.edu Tue Dec 8 12:03:55 2020 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 8 Dec 2020 07:03:55 -0500 Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2] In-Reply-To: References: Message-ID: On 12/8/20 3:56 AM, Alan Bateman wrote: >> 1558: break; >> 1559: } >> 1560: */ > Is this meant to be commented out? Yes, but It should be marked as a possible improvement, not yet committed. While this (prestarting) would improve performance in some scenarios, it may also disrupt expectations and even tooling in some existing usages, which we haven't fully checked out. From dwfranken at gmail.com Tue Dec 8 12:17:25 2020 From: dwfranken at gmail.com (Dave Franken) Date: Tue, 8 Dec 2020 13:17:25 +0100 Subject: Has it been considered to add inverse methods to collections which are in Optional? Message-ID: Dear all, The class java.util.Optional could be considered a collection with a limit on how many values it can hold, minimum 0, maximum 1. Likewise, any class implementing the regular java.util.Collection has a minimum, 0 and a maximum > 1. While Optional does not implement Collection, it could be seen as a pseudo-collection in this regard. Optional has a convenience method for which there is an inverse, isPresent() which is the inverse of isEmpty(). Has it been considered to add such a method (or other convenience methods) to collections as well? For instance, java.util.Collection has the method isEmpty() which behaves exactly like Optional's isEmpty(), but it does not have an inverse counterpart. I think it would be logical to add such as convenience method to Collection, because we have a precedent with Optional. We could add `bikeshed name here, as an example I'm going to use hasElements()' to java.util.Collection and, for simplicity's sake make the default implementation just call !isEmpty(); obviously implementations could offer optimized versions if necessary. It would improve readability where we have the negation of isEmpty(), e.g.: if (!myList.isEmpty()) { } // vs. if (myList.hasElements()) { } Note that in the first example, which is the current way of checking whether a (non null) collection has any elements, the negation and the method it negates are separated by the variable name. If the variable would instead be another method call or any other, longer, expression, this would make the example even less readable as the negation and final method call are further apart. The second example has the advantage of more clearly expressing the intent of the user - which is to check if the collection has any elements. Moreover, it offers matching functionality for something which already exists in the JDK core libs, Optional's isPresent(). If this has already been discussed and dismissed, I'm sorry for bringing it up again and if anybody could point me to the conclusion and the reasoning behind it, I would be grateful. Kind regards, Dave Franken From alanb at openjdk.java.net Tue Dec 8 12:18:20 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 12:18:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> Message-ID: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie wrote: >> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`! >> >> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`; or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter. > > Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`. The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Tue Dec 8 12:19:10 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 8 Dec 2020 12:19:10 GMT Subject: Integrated: 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 17:38:40 GMT, Maurizio Cimadamore wrote: > This simple patch updates the jaavdoc in the module-info file of jdk.incubator.foreign to reflect the fact that support of foreign function calls has been added. This pull request has now been integrated. Changeset: a7080247 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/a7080247 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary Reviewed-by: jvernee, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1671 From info at j-kuhn.de Tue Dec 8 13:07:45 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 8 Dec 2020 14:07:45 +0100 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> Message-ID: On 08-Dec-20 5:40, Mandy Chung wrote: > Thanks David.? I was about to create one. > > This is indeed a gap in injecting this trampoline class for supporting > @CallerSensitive methods.? The InjectedInvoker ensures that the > InjectedInvoker class has the same class loader as the lookup class.? > W.r.t. your patch, it seems okay but I have to consider and think > through the security implication carefully. > > You mentioned "Some old software loves to set static final fields > through reflection" - can you share some example libraries about > this??? This is really ugly hack!! > > Mandy Not sure if I read this correctly as "please share some example of code that tries to do that" or "please share code that you write to fix that". So I do both. Setting static final fields does not work [1]. It probably never really did. It usually seems to work - but there is no guarantee that it actually does (like undefined behavior). JPEXS [2] for example used that for it's configuration. Also some old Minecraft Forge version (a Minecraft mod loader / mod API) depends on this. Example use [3], but they do really ugly things. So, I said I develop agents to get old stuff running on a current Java version. Why? Fun, I guess. I also learn a lot a about what are the main comparability problems with newer Java versions. Pros of writing an agent: * I don't need the source code. * I don't need to setup a build environment with all dependencies, lombok and who knows what else is required. In all, it's faster for me. And I then have a list of problems - and how they can be solved. I did publish my JPESX agent here [4]. But yeah, it's an ugly hack. For the nestmate security consideration, the following invariants should already hold: * To call a @CallerSensitive method, the Lookup needs to have full privilege access (Lookup.hasFullPrivilegeAccess()) -> Injected Invokers are only created for full privilege lookups. * The injected invoker is in the same runtime package and has the same protection domain. * It is already possible to obtain a Lookup for the injected invoker by calling MethodHandles.lookup() through a MethodHandle (yikes) [5]. This means, we only have to consider what additional privileges the injected invoker gets if it is also a nestmate of the lookup class. I don't see any problem with that, as you already have a full privilege lookup when the injected invoker is created. - Johannes PS.: JDK-8013527 is mildly related - as the @CallerSensitive methods in java.lang.reflect are "hyper-sensitive". [1]: https://gist.github.com/DasBrain/25c6738610c517ee375aacc86ffebd0c [2]: https://github.com/akx/jpexs-decompiler/blob/6c998254b9d5bdce80be1b92d34836820ee31a1d/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/configuration/Configuration.java#L869 [3]: https://github.com/Chisel-Team/Chisel/blob/1.12/dev/src/main/java/team/chisel/common/init/ChiselBlocks.java#L18 [4]: https://github.com/DasBrain/jpex/tree/master/src/pw/dasbrain/jpexs/agent [5]: https://gist.github.com/DasBrain/142cb8ef9cc16e7469ac519790119e07 From forax at univ-mlv.fr Tue Dec 8 13:30:21 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 8 Dec 2020 14:30:21 +0100 (CET) Subject: Has it been considered to add inverse methods to collections which are in Optional? In-Reply-To: References: Message-ID: <381747107.1253228.1607434221870.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Dave Franken" > ?: "core-libs-dev" > Envoy?: Mardi 8 D?cembre 2020 13:17:25 > Objet: Has it been considered to add inverse methods to collections which are in Optional? > Dear all, Hi Dave, > > The class java.util.Optional could be considered a collection with a limit > on how many values it can hold, minimum 0, maximum 1. > Likewise, any class implementing the regular java.util.Collection has a > minimum, 0 and a maximum > 1. Optional is more considered as a Stream with 0 or 1 element. The primary usage of Optional is to temporary wraps a value (or not) as the result of a computation so it's not really like a collection which is a more "permanent" storage. > > While Optional does not implement Collection, it could be seen as a > pseudo-collection in this regard. > Optional has a convenience method for which there is an inverse, > isPresent() which is the inverse of isEmpty(). > > Has it been considered to add such a method (or other convenience methods) > to collections as well? > For instance, java.util.Collection has the method isEmpty() which behaves > exactly like Optional's isEmpty(), but it does not have an inverse > counterpart. Adding methods like notContains or notFilter have been considered several times in the past and rejected because it's too many methods with no real gain. I'm sure you can dig some old emails on lambda-dev and see the first iteration of the Stream API, it was full of convenient methods like that. I'm sure Stuart or Brian have a template answer for that :) > > I think it would be logical to add such as convenience method to > Collection, because we have a precedent with Optional. > We could add `bikeshed name here, as an example I'm going to use > hasElements()' to java.util.Collection and, for simplicity's sake make the > default implementation just call !isEmpty(); obviously implementations > could offer optimized versions if necessary. > > It would improve readability where we have the negation of isEmpty(), e.g.: > > if (!myList.isEmpty()) { > } > > // vs. > if (myList.hasElements()) { > } > > Note that in the first example, which is the current way of checking > whether a (non null) collection has any elements, the negation and the > method it negates are separated by the variable name. > If the variable would instead be another method call or any other, longer, > expression, this would make the example even less readable as the negation > and final method call are further apart. > > The second example has the advantage of more clearly expressing the intent > of the user - which is to check if the collection has any elements. > Moreover, it offers matching functionality for something which already > exists in the JDK core libs, Optional's isPresent(). Apart what i've said above, Java inherits from C its weird compact syntax, "if (!myList.isEmpty())" instead of "if myList is not empty" like in HyperCard, i'm not sure that trying to solve that by adding one or more method is not trying to put lipstick to a pig. We are used to that pig since a long time to the point we don't think of it as a pig. > > If this has already been discussed and dismissed, I'm sorry for bringing it > up again and if anybody could point me to the conclusion and the reasoning > behind it, I would be grateful. > > Kind regards, regards, > > Dave Franken R?mi From dfuchs at openjdk.java.net Tue Dec 8 13:46:17 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Dec 2020 13:46:17 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record In-Reply-To: <_LEx3RcGeEkkpCx-FSXwYFQWb8iY5rylfCwcRA-VT3Q=.8a146e10-8c58-465a-b130-0dcf269b2244@github.com> References: <_LEx3RcGeEkkpCx-FSXwYFQWb8iY5rylfCwcRA-VT3Q=.8a146e10-8c58-465a-b130-0dcf269b2244@github.com> Message-ID: On Tue, 8 Dec 2020 10:41:06 GMT, Julia Boes wrote: >> src/java.base/share/classes/java/lang/Enum.java line 62: >> >>> 60: * java.util.EnumMap map} implementations are available. >>> 61: * >>> 62: * @param The enum class subclass >> >> I wonder about this one, given that `` is a type. It sounds strange to me - even though I understand that what is meant is that this type should point to a class (a subclass of `java.lang.Enum`). > > Makes sense. I suggest the following instead: `The type of enum subclass`. Maybe: "`The type of the enum subclass.`" would sound better - or just "`The enum subclass`". ------------- PR: https://git.openjdk.java.net/jdk/pull/1670 From erik.joelsson at oracle.com Tue Dec 8 14:05:28 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 Dec 2020 06:05:28 -0800 Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> Message-ID: On 2020-12-08 00:30, Magnus Ihse Bursie wrote: > On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote: > >>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler` >> Hi Magnus, >> >> I see the motivation of moving these build files for better identification of ownership. Placing them under >> `src/$MODULE/{share,$OS}/data` is one option. Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration?? I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though. Do you see one option is better than the other? > @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`! > > This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`; or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter. > I strongly agree with Magnus for all the same reasons. To me, the data files are clearly a form of source code that should be considered owned by the component teams. I'm honestly perplexed over why this is being argued against. /Erik > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Tue Dec 8 14:10:26 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 8 Dec 2020 14:10:26 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 14:07:08 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256867: Classes with empty PermittedSubclasses attribute cannot be extended The langtools changes look good to me - thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1675 From hseigel at openjdk.java.net Tue Dec 8 14:10:26 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 8 Dec 2020 14:10:26 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1675/files - new: https://git.openjdk.java.net/jdk/pull/1675/files/89c61b95..de461457 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1675&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1675&range=00-01 Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1675.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1675/head:pull/1675 PR: https://git.openjdk.java.net/jdk/pull/1675 From hseigel at openjdk.java.net Tue Dec 8 14:26:14 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 8 Dec 2020 14:26:14 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 00:09:34 GMT, Mandy Chung wrote: >> src/hotspot/share/prims/jvm.cpp line 2130: >> >>> 2128: JvmtiVMObjectAllocEventCollector oam; >>> 2129: Array* subclasses = ik->permitted_subclasses(); >>> 2130: int length = subclasses == NULL ? 0 : subclasses->length(); >> >> Minor comment - you don't really need the check of subclasses == NULL here since subclasses will never be NULL. You could just assign length to subclasses->length(); > > +1. is_sealed returns true iff `_permitted_subclasses != NULL` Thanks for the reviews. I removed the check of subclasses == NULL in the updated commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From hseigel at openjdk.java.net Tue Dec 8 14:31:13 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 8 Dec 2020 14:31:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2] In-Reply-To: <0gY9SoxDO9oyPxcbLEKGp2Nv9JI1QTtk8OvCAqKvdtM=.51219b79-aa76-4e2d-bf93-0178a6f2e9b1@github.com> References: <0gY9SoxDO9oyPxcbLEKGp2Nv9JI1QTtk8OvCAqKvdtM=.51219b79-aa76-4e2d-bf93-0178a6f2e9b1@github.com> Message-ID: On Tue, 8 Dec 2020 09:30:59 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/java/lang/Class.java line 4396: >> >>> 4394: * is unspecified. If this {@code Class} object represents a primitive type, >>> 4395: * {@code void}, an array type, or a class or interface that is not sealed, >>> 4396: * then null is returned. >> >> nit: s/null/`{@code null}` >> >> I'd suggest to clarify if this sealed class or interface has no permitted subclass, something like this: >> Returns an array containing {@code Class} objects representing the >> direct subinterfaces or subclasses permitted to extend or >> implement this class or interface if it is sealed. The order of such elements >> is unspecified. The array is empty if this sealed class or interface has no >> permitted subclass. >> >> `@return` needs to be revised as well: >> @return an array of {@code Class} objects of the permitted subclasses of this sealed class or interface, >> or {@null} if this class or interface is not sealed > > Mandy's suggested wording is good. > > I would like to add one more additional point of clarification. It would > be good to strongly connect `isSealed` and `getPermittedClasses` in a > first-class way in normative spec ( similar to isRecord and > getRecordComponents ). > > For example, > > to `isSealed` add: "getPermittedSubclasses returns a non-null but possibly > empty value for a sealed class." > > to `getPermittedSubclasses`: "If this class is not a sealed class, that is {@link > * #isSealed()} returns {@code false}, then this method returns {@code null}. > * Conversely, if {@link #isSealed()} returns {@code true}, then this method > * returns a non-null value." Please review the updated commit. It incorporates the changes to the comments in Class.java suggested by Mandy and Chris. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From chegar at openjdk.java.net Tue Dec 8 14:41:13 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 8 Dec 2020 14:41:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 14:10:26 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256867: Classes with empty PermittedSubclasses attribute cannot be extended Thanks Harold. LGTM. src/java.base/share/classes/java/lang/Class.java line 4399: > 4397: * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}. > 4398: * Conversely, if {@link #isSealed()} returns {@code true}, then this method > 4399: * returns a non-null value." Trivially, the trailing quote can be removed. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1675 From hseigel at openjdk.java.net Tue Dec 8 14:53:13 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 8 Dec 2020 14:53:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 14:37:52 GMT, Chris Hegarty wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256867: Classes with empty PermittedSubclasses attribute cannot be extended > > src/java.base/share/classes/java/lang/Class.java line 4399: > >> 4397: * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}. >> 4398: * Conversely, if {@link #isSealed()} returns {@code true}, then this method >> 4399: * returns a non-null value." > > Trivially, the trailing quote can be removed. Thanks Chris! I'll remove the trailing quote. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From hseigel at openjdk.java.net Tue Dec 8 14:57:26 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 8 Dec 2020 14:57:26 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: References: Message-ID: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1675/files - new: https://git.openjdk.java.net/jdk/pull/1675/files/de461457..2ce2a993 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1675&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1675&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1675.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1675/head:pull/1675 PR: https://git.openjdk.java.net/jdk/pull/1675 From herrick at openjdk.java.net Tue Dec 8 14:59:11 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Dec 2020 14:59:11 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com> On Tue, 8 Dec 2020 03:08:59 GMT, Alexander Matveev wrote: > > > Looks like test failed due to: > [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity. > So, I am not sure how increased repeat will help. Do we know why it failed to parse XML? If you scroll down from that error - you can see that that is the expected error and the return code from jpackage is asserted to be 1, and it is asserted that the resulting WinL10NTest.msi does not exist. the @Parameters for "data" cause instance of this test to be run 8 times with different args. This instances is expected to fail since allWxlFilesValid is false. later in the log (https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-16+26-1740-tier2-20201124-1335-16116386-open_test_jdk_tier2_part2-windows-x64-125-1606226621-1556/log) you can see the timeout, where unpack.bat is run three times with 3 second delay and returns 1618 each time: **13:58:30.303] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O... [13:58:33.469] TRACE: exec: Done. Exit code: 1618 [13:58:36.492] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O... [13:58:39.636] TRACE: exec: Done. Exit code: 1618 [13:58:42.652] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O... [13:58:45.803] TRACE: exec: Done. Exit code: 1618 [13:58:48.832] ERROR: Expected [0]. Actual [1618]: Check command [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3) exited with 0 code [13:58:48.832] [ FAILED ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=fr](length=2), fr;en-us, null).test; checks=17 [13:58:48.832] [ RUN ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=it, name=c.wxl; culture=fr, name=d.wxl; culture=it](length=4), fr;it;en-us,** running unpack.bat with msiexec command in it succeed for one test instance after the expected failure, then got 1618 return on the second test instance after the expected failure with the above timeout. ------------- PR: https://git.openjdk.java.net/jdk/pull/1676 From chegar at openjdk.java.net Tue Dec 8 15:02:13 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 8 Dec 2020 15:02:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> References: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> Message-ID: On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256867: Classes with empty PermittedSubclasses attribute cannot be extended Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From herrick at openjdk.java.net Tue Dec 8 15:11:50 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Dec 2020 15:11:50 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 [v2] In-Reply-To: References: Message-ID: > increase retries and timeout increasing in runMsiexecWithRetries Andy Herrick has updated the pull request incrementally with 18 additional commits since the last revision: - 8256149: Weird AST structure for incomplete member select Reviewed-by: vromero - 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary Reviewed-by: jvernee, shade - 8257848: -XX:CompileCommand=blackhole,* should be diagnostic Reviewed-by: vlivanov - 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input Reviewed-by: alanb - 8254733: HotSpot Style Guide should permit using range-based for loops Reviewed-by: dholmes, pliden, jrose, dcubed, iklam, eosterlund, tschatzl, kvn - 8253644: C2: assert(skeleton_predicate_has_opaque(iff)) failed: unexpected Reviewed-by: roland, kvn - 8256411: Based anonymous classes have a weird end position Reviewed-by: vromero - 8257813: [redo] C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops Reviewed-by: chagedorn, kvn - 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305 Reviewed-by: mullan, valeriep - 8257855: Example SafeVarargsNotApplicableToRecordAccessors breaks test tools/javac/diags/CheckExamples.java Reviewed-by: jjg - ... and 8 more: https://git.openjdk.java.net/jdk/compare/7c4743c5...5d065497 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1676/files - new: https://git.openjdk.java.net/jdk/pull/1676/files/7c4743c5..5d065497 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1676&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1676&range=00-01 Stats: 1938 lines in 49 files changed: 1465 ins; 276 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/1676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1676/head:pull/1676 PR: https://git.openjdk.java.net/jdk/pull/1676 From rriggs at openjdk.java.net Tue Dec 8 15:20:16 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Dec 2020 15:20:16 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks wrote: >> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: >> >> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! >> >> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. >> >> Separately, I'll work on retrofitting various call sites around the JDK to use this method. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > fix typo, clarify asserts disabled, test prefGrowth==0 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From rriggs at openjdk.java.net Tue Dec 8 15:20:16 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Dec 2020 15:20:16 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v2] In-Reply-To: <7j7UdFeKB6m-L1xarpTVxcUOQZT7Dq5UOFWP6_0hSVA=.229451c0-b846-4d68-b4f6-3937e295f238@github.com> References: <7j7UdFeKB6m-L1xarpTVxcUOQZT7Dq5UOFWP6_0hSVA=.229451c0-b846-4d68-b4f6-3937e295f238@github.com> Message-ID: On Tue, 8 Dec 2020 00:48:55 GMT, Stuart Marks wrote: >> The algorithm can be well defined for minGrowth and prefGrowth == 0 without extra checks or exceptions with a careful look at the inequality checks. >> For example, as currently coded, if both are zero, it returns SOFT_MAX_ARRAY_LENGTH. >> Changing the `0 < prefLength` to `0 <= prefLength` would return minGrowth and avoid a very large but unintentional allocation. > > That's only true if oldLength is zero. The behavior is different if oldLength is positive. In any case, this method is called when the array needs to **grow**, which means the caller needs to reallocate and copy. If the caller passes zero for both minGrowth and prefGrowth, the caller doesn't need to reallocate and copy, and there's no point in it calling this method in the first place. Not calling for a zero value is usually an optimization, not a necessity to work around an inconsistency or unpredictability in the API or the range of arguments it accepts. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From weijun at openjdk.java.net Tue Dec 8 15:28:11 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Dec 2020 15:28:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> Message-ID: On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote: >> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`. > > The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Dec 8 16:20:21 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 8 Dec 2020 16:20:21 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> Message-ID: On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote: >> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`. > > The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html: > As to charsetmapping and cldrconverter, I believe they can reside in java.base, as jdk.charsets and jdk.localedata modules depend on it. Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart. Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jboes at openjdk.java.net Tue Dec 8 16:21:09 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 8 Dec 2020 16:21:09 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record [v2] In-Reply-To: References: Message-ID: > This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. > > The following rules were applied: > - 'class' and/or 'interface' are used when referring to the class/interface itself > - 'type' is used when referring to the type of a variable or expression Julia Boes has updated the pull request incrementally with one additional commit since the last revision: adjust 1 change in Enum.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1670/files - new: https://git.openjdk.java.net/jdk/pull/1670/files/6a2a55ea..36b7ceb0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1670&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1670&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1670/head:pull/1670 PR: https://git.openjdk.java.net/jdk/pull/1670 From herrick at openjdk.java.net Tue Dec 8 16:25:03 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Dec 2020 16:25:03 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com> References: <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com> Message-ID: On Tue, 8 Dec 2020 14:56:20 GMT, Andy Herrick wrote: >> Looks like test failed due to: >> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity. >> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML? > >> >> >> Looks like test failed due to: >> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity. >> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML? > > If you scroll down from that error - you can see that that is the expected error and the return code from jpackage is asserted to be 1, and it is asserted that the resulting WinL10NTest.msi does not exist. > > the @Parameters for "data" cause instance of this test to be run 8 times with different args. This instances is expected to fail since allWxlFilesValid is false. > later in the log (https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-16+26-1740-tier2-20201124-1335-16116386-open_test_jdk_tier2_part2-windows-x64-125-1606226621-1556/log) you can see the timeout, where unpack.bat is run three times with 3 second delay and returns 1618 each time: > **13:58:30.303] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O... > [13:58:33.469] TRACE: exec: Done. Exit code: 1618 > [13:58:36.492] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O... > [13:58:39.636] TRACE: exec: Done. Exit code: 1618 > [13:58:42.652] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O... > [13:58:45.803] TRACE: exec: Done. Exit code: 1618 > [13:58:48.832] ERROR: Expected [0]. Actual [1618]: Check command [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3) exited with 0 code > [13:58:48.832] [ FAILED ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=fr](length=2), fr;en-us, null).test; checks=17 > [13:58:48.832] [ RUN ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=it, name=c.wxl; culture=fr, name=d.wxl; culture=it](length=4), fr;it;en-us,** > > running unpack.bat with msiexec command in it succeed for one test instance after the expected failure, then got 1618 return on the second test instance after the expected failure with the above timeout. I converted to draft because somehow merging with master caused a mess - since is simple change in one test file I may create a new branch and new pull request cleanly again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1676 From ihse at openjdk.java.net Tue Dec 8 16:25:06 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 8 Dec 2020 16:25:06 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> Message-ID: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com> On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang wrote: >> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. > > Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well? > > Update: I see all subdirs in tools are still there. @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463. I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From github.com+1709517+mariusvolkhart at openjdk.java.net Tue Dec 8 16:25:25 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Tue, 8 Dec 2020 16:25:25 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v4] In-Reply-To: References: Message-ID: <1KBn-xs9tpJVkfq2TLG8Ft6FCUy_4rNq7y5cWNqa4Kg=.93ce85e5-839e-4c3b-b9db-5fa06c2f3d99@github.com> > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. Marius Volkhart has updated the pull request incrementally with two additional commits since the last revision: - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1056/files - new: https://git.openjdk.java.net/jdk/pull/1056/files/0fa81e46..68ab39aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1056&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1056&range=02-03 Stats: 79 lines in 4 files changed: 25 ins; 46 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1056/head:pull/1056 PR: https://git.openjdk.java.net/jdk/pull/1056 From github.com+1709517+mariusvolkhart at openjdk.java.net Tue Dec 8 16:26:05 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Tue, 8 Dec 2020 16:26:05 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v4] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:40:40 GMT, Joe Wang wrote: >> Marius Volkhart has updated the pull request incrementally with two additional commits since the last revision: >> >> - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event >> - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java line 136: > >> 134: if (streamReader.standaloneSet()) { >> 135: sdEvent.setStandalone(streamReader.isStandalone()); >> 136: } > > The change looked fine at the first glance. However, when I looked at your test, I noticed that in your first test case, isStandalone will return true. This is because standalone was initiated as true and with the added condition, setStandalone is skipped. > > To fix the issue, consider, instead of making it conditional, adding standaloneSet to the setStandalone method. > > Pls update the copyright year at line 2, e.g. 2016 -> 2020. Updates made. I understood your comment about modifying the `setStandalone` method to mean `StartDocumentEvent#setStandalone`. If it was something else, please let me know! ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From chegar at openjdk.java.net Tue Dec 8 16:28:12 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 8 Dec 2020 16:28:12 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:21:09 GMT, Julia Boes wrote: >> This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. >> >> The following rules were applied: >> - 'class' and/or 'interface' are used when referring to the class/interface itself >> - 'type' is used when referring to the type of a variable or expression > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > adjust 1 change in Enum.java Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1670 From dfuchs at openjdk.java.net Tue Dec 8 16:31:16 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Dec 2020 16:31:16 GMT Subject: RFR: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:21:09 GMT, Julia Boes wrote: >> This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. >> >> The following rules were applied: >> - 'class' and/or 'interface' are used when referring to the class/interface itself >> - 'type' is used when referring to the type of a variable or expression > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > adjust 1 change in Enum.java Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1670 From darcy at openjdk.java.net Tue Dec 8 16:44:25 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 16:44:25 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == Message-ID: Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. Once the wording is worked out, I'll replicate it for the analogous methods on Float. ------------- Commit messages: - Fix whitespace - Initial work for JDK-8257086. Changes: https://git.openjdk.java.net/jdk/pull/1699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257086 Stats: 65 lines in 1 file changed: 47 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699 PR: https://git.openjdk.java.net/jdk/pull/1699 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Dec 8 16:51:05 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 8 Dec 2020 16:51:05 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v2] In-Reply-To: <60CyX-zWhx9EA7xs7Kt9D0ut7hF6c3DhHUn2UaAonho=.2fee02bd-42eb-4ca5-86c6-3b200b944663@github.com> References: <60CyX-zWhx9EA7xs7Kt9D0ut7hF6c3DhHUn2UaAonho=.2fee02bd-42eb-4ca5-86c6-3b200b944663@github.com> Message-ID: <4sZNfZX8UVXkdTDIIHWbR9qlNbXwEbcYHvLLJ4MBKSg=.00fd3ac4-6310-4f47-8159-be9b00eeeb89@github.com> On Fri, 4 Dec 2020 20:48:01 GMT, Daniel Fuchs wrote: >> test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java line 80: >> >>> 78: creator.buildSignedMultiReleaseJar(); >>> 79: >>> 80: server = new SimpleHttpServer(TESTCONTEXT,System.getProperty("user.dir", ".")); >> >> Please add space after comma. > > I believe the InetAddress parameter should be preserved in order to allow test to specifically bind to the loopback address instead of the wildcard (binding to the wildcard has been a source of test instability in the past). Thanks. Review comments are fixed in next patch ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Dec 8 16:51:02 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 8 Dec 2020 16:51:02 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v2] In-Reply-To: References: Message-ID: > jaxp.library.SimpleHttpServer > https://bugs.openjdk.java.net/browse/JDK-8212035 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1632/files - new: https://git.openjdk.java.net/jdk/pull/1632/files/f48a3f7a..71fc7e9f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=00-01 Stats: 145 lines in 3 files changed: 26 ins; 33 del; 86 mod Patch: https://git.openjdk.java.net/jdk/pull/1632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632 PR: https://git.openjdk.java.net/jdk/pull/1632 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Dec 8 16:51:09 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 8 Dec 2020 16:51:09 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 20:45:24 GMT, Daniel Fuchs wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > test/lib/jdk/test/lib/net/SimpleHttpServer.java line 95: > >> 93: return _httpserver.getAddress().getPort(); >> 94: } >> 95: > > There are many issues with this class - using "localhost" and binding to the wildcard address among others. > Having instance variables that are not final but are accessed by potentially multiple threads is another. > I could also mention not using try-with-resources or the odd _name convention. > It will need to be modernized if you want to put it in jdk.test.lib.net; Thanks. Now this class is modernized in next patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From darcy at openjdk.java.net Tue Dec 8 17:10:30 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 17:10:30 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v5] In-Reply-To: References: Message-ID: > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Update symbol files for JDK 16b27. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - JDK-8257450 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e5462611...ff9b78ec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/342c8650..ff9b78ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=03-04 Stats: 1427 lines in 38 files changed: 1106 ins; 191 del; 130 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From bpb at openjdk.java.net Tue Dec 8 17:14:11 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Dec 2020 17:14:11 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:29:49 GMT, Joe Darcy wrote: > Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. > > Once the wording is worked out, I'll replicate it for the analogous methods on Float. src/java.base/share/classes/java/lang/Double.java line 811: > 809: * > 810: *

also has the value {@code true}. However, there are two > 811: * exceptions where the properties of an equivalence relations are type: relations -> relation. src/java.base/share/classes/java/lang/Double.java line 1008: > 1006: * This method imposes a total order on {@code Double} objects > 1007: * with two differences compared to the incomplete order defined the > 1008: * by Java language numerical comparison operators ({@code <, <=, Typo: defined the by Java -> defined by the Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/1699 From adityam at openjdk.java.net Tue Dec 8 17:21:12 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Tue, 8 Dec 2020 17:21:12 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:54:41 GMT, Aleksey Shipilev wrote: > See here: > https://github.com/mcimadamore/jdk/runs/1460615378 > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java > > STDERR: > Invalid maximum heap size: -Xmx4G > The specified size exceeds the maximum representable size. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. > > Additional testing: > - [x] Affected test on Linux x86_32 (skipped now) > - [x] Affected test on Linux x86_64 (still passes) Marked as reviewed by adityam (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From jjg at openjdk.java.net Tue Dec 8 17:22:02 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Dec 2020 17:22:02 GMT Subject: RFR: 6882207: Convert javap to use diamond operator internally In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:30:07 GMT, Andrey Turbanov wrote: > 6882207: Convert javap to use diamond operator internally Nice; thanks ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1677 From mchung at openjdk.java.net Tue Dec 8 17:23:19 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 17:23:19 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> References: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> Message-ID: On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256867: Classes with empty PermittedSubclasses attribute cannot be extended src/java.base/share/classes/java/lang/Class.java line 4399: > 4397: * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}. > 4398: * Conversely, if {@link #isSealed()} returns {@code true}, then this method > 4399: * returns a non-null value. @ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows: implement this class or interface if it is {@linkplain #isSealed() sealed}. The order of such elements is unspecified. If this {@code Class} object represents a primitive type, is unspecified. The array is empty if this {@linkplain #isSealed() sealed} class or interface has no permitted subclass. If this {@code Class} object represents a primitive type, {@code void}, an array type, or a class or interface that is not sealed, then this method returns {@code null}. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From mchung at openjdk.java.net Tue Dec 8 17:33:04 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 17:33:04 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: References: Message-ID: <2TbNnDlF1nuEFWLddNG3wdj5EL0gg-1hzGwe2-emoQE=.e950f0f7-6be0-426d-8634-bc3c3175030a@github.com> On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote: > Please review this change that eliminates the use of Reference.isEnqueued by > tests. There were three tests using it: > > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java > jdk/java/lang/ref/ReferenceEnqueue.java > > In each of them, some combination of using Reference.refersTo and > ReferenceQueue.remove with a timeout were used to eliminate the use of > Reference.isEnqueued. > > I also cleaned up ReferencesGC.java in various respects. It contained > several bits of dead code, and the failure checks were made stronger. > > Testing: > mach5 tier1 > Locally (linux-x64) ran all three tests with each GC (including Shenandoah). Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From alanb at openjdk.java.net Tue Dec 8 17:36:08 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 17:36:08 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> Message-ID: On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote: >> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`. > > The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. > @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From chegar at openjdk.java.net Tue Dec 8 17:41:09 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 8 Dec 2020 17:41:09 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: References: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> Message-ID: <1eiv5vks958dAH0lTcXvEbWancK8w6jLTUITk1s4W8k=.ce9c67a2-6b30-4ff9-a095-4ab03eea3bc5@github.com> On Tue, 8 Dec 2020 17:18:20 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256867: Classes with empty PermittedSubclasses attribute cannot be extended > > src/java.base/share/classes/java/lang/Class.java line 4399: > >> 4397: * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}. >> 4398: * Conversely, if {@link #isSealed()} returns {@code true}, then this method >> 4399: * returns a non-null value. > > @ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows: > implement this class or interface if it is {@linkplain #isSealed() sealed}. > The order of such elements is unspecified. If this {@code Class} object > represents a primitive type, is unspecified. The array is empty if this > {@linkplain #isSealed() sealed} class or interface has no permitted subclass. > If this {@code Class} object represents a primitive type, {@code void}, an array type, > or a class or interface that is not sealed, then this method returns {@code null}. There is certainly a little redundancy in the additional spec wording that I proposed. In my view it is worth it, as it allows the reader to more easily grok the null versus empty array for non-sealed classes, without having to navigate between the pair of methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From smarks at openjdk.java.net Tue Dec 8 18:02:11 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Dec 2020 18:02:11 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == In-Reply-To: References: Message-ID: <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com> On Tue, 8 Dec 2020 16:29:49 GMT, Joe Darcy wrote: > Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. > > Once the wording is worked out, I'll replicate it for the analogous methods on Float. I'll note initially that the original bug is about `equals` and `==` whereas this change also covers `compareTo` and additional comparison operators `<` and `>`. I believe covering this additional material **IS** important, as these concepts are all closely related. While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice. (One additional concept that ought to be covered is that `compareTo` is *consistent with equals*. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.) I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in `Double`. The various methods can then make some terse assertions and then refer to the combined explanation. `Float` could refer to `Double` instead of replicating the text. Another alternative is to put this explanation into the `java.lang` package specification. This might be a good fit, since there is already some explanation there of the boxed primitives. ------------- PR: https://git.openjdk.java.net/jdk/pull/1699 From bchristi at openjdk.java.net Tue Dec 8 18:05:14 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 8 Dec 2020 18:05:14 GMT Subject: Integrated: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:23:55 GMT, Brent Christian wrote: > Please review this fix for the intermittently-failing java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java. > > The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic used elsewhere in the test base, [as pointed out by Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!). > > The new version of the test passes 100 times out of 100 on the test farm. This pull request has now been integrated. Changeset: 1a9ed92d Author: Brent Christian URL: https://git.openjdk.java.net/jdk/commit/1a9ed92d Stats: 12 lines in 1 file changed: 4 ins; 1 del; 7 mod 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected Reviewed-by: mchung, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/1630 From mchung at openjdk.java.net Tue Dec 8 18:06:15 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 18:06:15 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: <1eiv5vks958dAH0lTcXvEbWancK8w6jLTUITk1s4W8k=.ce9c67a2-6b30-4ff9-a095-4ab03eea3bc5@github.com> References: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> <1eiv5vks958dAH0lTcXvEbWancK8w6jLTUITk1s4W8k=.ce9c67a2-6b30-4ff9-a095-4ab03eea3bc5@github.com> Message-ID: On Tue, 8 Dec 2020 17:38:12 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/java/lang/Class.java line 4399: >> >>> 4397: * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}. >>> 4398: * Conversely, if {@link #isSealed()} returns {@code true}, then this method >>> 4399: * returns a non-null value. >> >> @ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows: >> implement this class or interface if it is {@linkplain #isSealed() sealed}. >> The order of such elements is unspecified. If this {@code Class} object >> represents a primitive type, is unspecified. The array is empty if this >> {@linkplain #isSealed() sealed} class or interface has no permitted subclass. >> If this {@code Class} object represents a primitive type, {@code void}, an array type, >> or a class or interface that is not sealed, then this method returns {@code null}. > > There is certainly a little redundancy in the additional spec wording > that I proposed. In my view it is worth it, as it allows the reader to > more easily grok the null versus empty array for non-sealed classes, > without having to navigate between the pair of methods. I see this new pattern introduced in `getRecordComponents`. You may consider if this pattern should consistently applied in other `Class` APIs such as `getEnumConstants`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From mchung at openjdk.java.net Tue Dec 8 18:20:07 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 18:20:07 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com> Message-ID: On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie wrote: >> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well? >> >> Update: I see all subdirs in tools are still there. > > @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463. > > I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion. @magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair. You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure. I reviewed this patch and this looks okay to me. Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`? There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up. I agree that this should be cleaned up by the component teams and not part of this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mchung at openjdk.java.net Tue Dec 8 18:24:08 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 18:24:08 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com> Message-ID: On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung wrote: >> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463. >> >> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion. > > @magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair. You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure. > > I reviewed this patch and this looks okay to me. Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`? There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up. I agree that this should be cleaned up by the component teams and not part of this PR. With these new files showing up in under `src` directory, should `bin/idea.sh` be changed to exclude `data` to avoid incurring costs in loading JDK project from IDE that many of us use for development? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mchung at openjdk.java.net Tue Dec 8 18:27:09 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 18:27:09 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> References: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> Message-ID: On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. >> >> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. >> >> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256867: Classes with empty PermittedSubclasses attribute cannot be extended Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From mchung at openjdk.java.net Tue Dec 8 18:33:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 18:33:16 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v5] In-Reply-To: References: Message-ID: <-0FTWuV91_n7GwB4Om2qXb6LsQh7YxKq2ZCq4qSITGQ=.8955f873-e2ca-4eb1-a1d8-f295cdcab9c9@github.com> On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'master' into JDK-8257450 > - Update symbol files for JDK 16b27. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - JDK-8257450 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c3d62067...ff9b78ec Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From akozlov at openjdk.java.net Tue Dec 8 18:34:09 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 8 Dec 2020 18:34:09 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com> Message-ID: On Thu, 3 Dec 2020 06:50:11 GMT, Anton Kozlov wrote: >> Filed https://bugs.openjdk.java.net/browse/JDK-8257633 > > Thanks for taking care of those issues. To be clear, there is no real need to bump the version for this PR, 10.9 is fine. This PR just proposes another way to implement the workaround for 10.9. Hi, could I get review of the patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From hseigel at openjdk.java.net Tue Dec 8 18:35:13 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 8 Dec 2020 18:35:13 GMT Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3] In-Reply-To: References: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com> Message-ID: On Tue, 8 Dec 2020 18:24:21 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256867: Classes with empty PermittedSubclasses attribute cannot be extended > > Marked as reviewed by mchung (Reviewer). Thanks Mandy, Chris, Lois, and Jan for reviewing this change. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From naoto at openjdk.java.net Tue Dec 8 18:44:10 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Dec 2020 18:44:10 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> Message-ID: On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote: >> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. > >> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. > > This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module. > @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. > > I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html: > > > As to charsetmapping and cldrconverter, I believe they can reside in > > java.base, as jdk.charsets and jdk.localedata modules depend on it. > > Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart. > > Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place. I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From shade at openjdk.java.net Tue Dec 8 18:53:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 18:53:12 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: <2HQwixG2RtV4UtejZRNhKonMhzPkcV_vRMnDAEM-u-E=.ac9ba0cc-440f-45c2-8ad0-49f5b7c6c751@github.com> On Tue, 8 Dec 2020 17:17:54 GMT, Aditya Mandaleeka wrote: >> See here: >> https://github.com/mcimadamore/jdk/runs/1460615378 >> >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java >> >> STDERR: >> Invalid maximum heap size: -Xmx4G >> The specified size exceeds the maximum representable size. >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. >> >> Additional testing: >> - [x] Affected test on Linux x86_32 (skipped now) >> - [x] Affected test on Linux x86_64 (still passes) > > Marked as reviewed by adityam (Author). Thanks folks! I need a formal Reviewer ack. @mcimadamore? This would make GH testing clean again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From mchung at openjdk.java.net Tue Dec 8 18:53:30 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 18:53:30 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue [v2] In-Reply-To: References: Message-ID: > `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. > > This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into isEnqueued - Merge branch 'master' of https://github.com/openjdk/jdk into isEnqueued - add suppress warnings - 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1684/files - new: https://git.openjdk.java.net/jdk/pull/1684/files/7549cdc4..b4f9b489 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1684&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1684&range=00-01 Stats: 1325 lines in 35 files changed: 1010 ins; 175 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/1684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1684/head:pull/1684 PR: https://git.openjdk.java.net/jdk/pull/1684 From joehw at openjdk.java.net Tue Dec 8 19:15:45 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 8 Dec 2020 19:15:45 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v4] In-Reply-To: <1KBn-xs9tpJVkfq2TLG8Ft6FCUy_4rNq7y5cWNqa4Kg=.93ce85e5-839e-4c3b-b9db-5fa06c2f3d99@github.com> References: <1KBn-xs9tpJVkfq2TLG8Ft6FCUy_4rNq7y5cWNqa4Kg=.93ce85e5-839e-4c3b-b9db-5fa06c2f3d99@github.com> Message-ID: On Tue, 8 Dec 2020 16:25:25 GMT, Marius Volkhart wrote: >> The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. >> >> The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. > > Marius Volkhart has updated the pull request incrementally with two additional commits since the last revision: > > - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event > - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From ihse at openjdk.java.net Tue Dec 8 19:15:46 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 8 Dec 2020 19:15:46 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com> <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com> Message-ID: On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote: >> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too. > >> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. > > This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module. @AlanBateman @mlchung @naotoj I can certainly anticipate follow-up cleanups on this patch. In fact, I think this patch has the potential to be a catalyst for such change, since the data that has been "hidden away" in `make` now becomes more visible to the teams that are capable of doing something about it. (With that said, of course the build team will assist in helping to clear up messy code structure, as we always do.) But I think we should be restrictive in trying too hard to make everything right in this single patch; it's better to get things approximately right and then go through the "warts" one by one and solve them properly. @AlanBateman What I meant by Jigsaw was that when the monolithic source code were modularized, the separation of concern between java.base and jdk.charsets/jdk.localedata was not complete, compared to (more or less) all other modules. It might very well be the case that we will never be able to make such a separation; but, prior to Jigsaw, this was not a "wart". It only became a code hygiene issue when some of the charsets and localedata was extraced from java.base. @mlchung My gut reaction is that we should not change idea.sh. First of all, kind of the purpose of this move is to make it clear to module developers the full set of materials their module consists of. That purpose would be sort of defeated, if we were to hide this in a popular IDE configuration. Secondly, I doubt this will add any performance difference. Listing additional files in the workspace is unlikely to do much, unless you actively open and/or interact with these files. But if you are worried, please fetch the PR (Skara adds instructions in the body) and try it out yourself! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Tue Dec 8 19:35:03 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 8 Dec 2020 19:35:03 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v12] In-Reply-To: References: Message-ID: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: - Merging recent master changes into JDK-8250768 - Fixing navigator for the PREVIEW page. - Fixing typo. - Removing obsolette @PreviewFeature. - Merging master into JDK-8250768 - Removing unnecessary property keys. - Cleanup - removing unnecessary code. - Merging master into JDK-8250768-dev4 - Reflecting review comments. - Removing trailing whitespace. - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57 ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=11 Stats: 3711 lines in 132 files changed: 2726 ins; 692 del; 293 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From alanb at openjdk.java.net Tue Dec 8 19:38:39 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Dec 2020 19:38:39 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 18:53:30 GMT, Mandy Chung wrote: >> `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. >> >> This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into isEnqueued > - Merge branch 'master' of https://github.com/openjdk/jdk into isEnqueued > - add suppress warnings > - 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue src/java.base/share/classes/java/lang/ref/Reference.java line 430: > 428: * This method was never implemented to test if a reference object has > 429: * been cleared and enqueued as it was previously specified since 1.2. > 430: * This method could be misused due to the inherent race condition A small suggestion is to restructure the first sentence of the deprecated message to say "This method was originally specified to test .. but was never implemented to do this test", otherwise looks okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1684 From martinrb at google.com Tue Dec 8 19:53:18 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2020 11:53:18 -0800 Subject: RFR: 8246585: ForkJoin updates In-Reply-To: References: Message-ID: On Tue, Dec 8, 2020 at 12:05 AM Aleksey Shipilev wrote: > On Sun, 6 Dec 2020 02:56:34 GMT, Martin Buchholz > wrote: > > > 8246585: ForkJoin updates > > It would be nice to get it tested with GH Actions. "Checks" tabs should > have those testing results automatically on push, but it is empty. Probably > because your fork is not configured for it. Please go to > https://github.com/Martin-Buchholz/jdk/actions -- and see if it says > anything suspicious? Triggering the (only) workflow manually against your > branch would help too. > Thanks for the handholding. I visited https://github.com/Martin-Buchholz/jdk/actions and it said Workflows aren't being run on this forked repository Because this repository contained workflow files when it was forked, we have disabled them from running on this fork. Make sure you understand the configured workflows and their expected usage before enabling Actions on this repository. They're now enabled. Do the skara docs need to clarify this? From mchung at openjdk.java.net Tue Dec 8 20:14:37 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 20:14:37 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue [v2] In-Reply-To: References: Message-ID: <7M6tyPIxZKOsXnxtQXmE5dUlW80Una3LYlFuUbnsXqU=.00824c73-30ef-42a6-93d4-2d5a3c99d1c5@github.com> On Tue, 8 Dec 2020 19:35:39 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into isEnqueued >> - Merge branch 'master' of https://github.com/openjdk/jdk into isEnqueued >> - add suppress warnings >> - 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue > > src/java.base/share/classes/java/lang/ref/Reference.java line 430: > >> 428: * This method was never implemented to test if a reference object has >> 429: * been cleared and enqueued as it was previously specified since 1.2. >> 430: * This method could be misused due to the inherent race condition > > A small suggestion is to restructure the first sentence of the deprecated message to say "This method was originally specified to test .. but was never implemented to do this test", otherwise looks okay. Yes, it reads better and we can also drop "as it was previously specified since 1.2". * This method was originally specified to test if a reference object has * been cleared and enqueued but was never implemented to do this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1684 From joehw at openjdk.java.net Tue Dec 8 20:27:36 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 8 Dec 2020 20:27:36 GMT Subject: RFR: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event [v4] In-Reply-To: References: <1KBn-xs9tpJVkfq2TLG8Ft6FCUy_4rNq7y5cWNqa4Kg=.93ce85e5-839e-4c3b-b9db-5fa06c2f3d99@github.com> Message-ID: <41vjLiJFN95pdSdMCf7wRmAxIDHhGEQu-j4yj7v05YY=.9cd326e0-91e1-490a-8da3-2ad54f1daa43@github.com> On Tue, 8 Dec 2020 19:10:37 GMT, Joe Wang wrote: >> Marius Volkhart has updated the pull request incrementally with two additional commits since the last revision: >> >> - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event >> - fixup! Fix: javax.xml.stream.XMLEventReader produces incorrect START_DOCUMENT event > > Marked as reviewed by joehw (Reviewer). Hi Marius, As the bot suggested, this PR is ready to be integrated. You may issue the integrate command when you're ready, I'll then sponsor it for you. Thanks for contributing the fix! Regards, Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From martinrb at google.com Tue Dec 8 20:34:55 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2020 12:34:55 -0800 Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2] In-Reply-To: References: Message-ID: OK, rollback committed to CVS: --- src/main/java/util/concurrent/ThreadPoolExecutor.java 27 Nov 2020 17:42:00 -0000 1.194 +++ src/main/java/util/concurrent/ThreadPoolExecutor.java 8 Dec 2020 20:31:54 -0000 @@ -1522,13 +1522,11 @@ // As a heuristic, prestart enough new workers (up to new // core size) to handle the current number of tasks in // queue, but stop if queue becomes empty while doing so. - /* int k = Math.min(delta, workQueue.size()); while (k-- > 0 && addWorker(null, true)) { if (workQueue.isEmpty()) break; } - */ } } On Tue, Dec 8, 2020 at 4:04 AM Doug Lea

wrote: > > On 12/8/20 3:56 AM, Alan Bateman wrote: > >> 1558: break; > >> 1559: } > >> 1560: */ > > Is this meant to be commented out? > Yes, but It should be marked as a possible improvement, not yet > committed. While this (prestarting) would improve performance in some > scenarios, it may also disrupt expectations and even tooling in some > existing usages, which we haven't fully checked out. > > From mchung at openjdk.java.net Tue Dec 8 20:42:52 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 20:42:52 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue [v3] In-Reply-To: References: Message-ID: > `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. > > This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: improve the deprecation message per feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1684/files - new: https://git.openjdk.java.net/jdk/pull/1684/files/b4f9b489..9acf8a56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1684&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1684&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1684/head:pull/1684 PR: https://git.openjdk.java.net/jdk/pull/1684 From github.com+1709517+mariusvolkhart at openjdk.java.net Tue Dec 8 20:46:36 2020 From: github.com+1709517+mariusvolkhart at openjdk.java.net (Marius Volkhart) Date: Tue, 8 Dec 2020 20:46:36 GMT Subject: Integrated: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 14:01:53 GMT, Marius Volkhart wrote: > The default implementation of javax.xml.stream.XMLEventReader produced a StartDocument event that always indicated that the "standalone" attribute was set. > > The root cause of this was that the com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the "standalone" attribute, rather than asking streamReader.standaloneSet() before setting the property of the StartDocumentEvent being created. This pull request has now been integrated. Changeset: c47ab5f6 Author: Marius Volkhart Committer: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/c47ab5f6 Stats: 33 lines in 3 files changed: 25 ins; 0 del; 8 mod 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/1056 From martinrb at google.com Tue Dec 8 20:47:46 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2020 12:47:46 -0800 Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Mon, Dec 7, 2020 at 11:56 PM Alan Bateman wrote: > > > 37: // TODO: Rewrite as a CompletableFuture tck test ? > > Do you want the "TODO" in the commit? > > Yes! From martinrb at google.com Tue Dec 8 20:54:30 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2020 12:54:30 -0800 Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Tue, Dec 8, 2020 at 3:54 AM Daniel Fuchs wrote: > > > RandomFactory is probably overkill here as the test just needs to > exercise untimed and timed get. So just a random boolean rather than a wide > range of random values. > > OK. > There's a conflict between the desires to do more thorough testing and avoid flaky intermittent failures. Especially in j.u.concurrent we embrace test non-determinism, much of it comes from the concurrency we're testing, and retrieving a random seed for reproducibility is not worth the effort. No one does a good job of race prevention through testing. From jjg at openjdk.java.net Tue Dec 8 21:05:41 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 8 Dec 2020 21:05:41 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v5] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 09:22:18 GMT, Jan Lahoda wrote: >> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: >> -updating and moving tests into test/langtools, so that it is easier to run them. >> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). >> -fixing the -Xprint annotation processor to print record component annotations. >> >> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Blank lines do not count for the text block indentation, removing them. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From martin at openjdk.java.net Tue Dec 8 21:15:48 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 8 Dec 2020 21:15:48 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3] In-Reply-To: References: Message-ID: > 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: JDK-8234131 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1647/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1647&range=02 Stats: 312 lines in 41 files changed: 105 ins; 41 del; 166 mod Patch: https://git.openjdk.java.net/jdk/pull/1647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1647/head:pull/1647 PR: https://git.openjdk.java.net/jdk/pull/1647 From darcy at openjdk.java.net Tue Dec 8 22:02:36 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 22:02:36 GMT Subject: RFR: 8257845: Integrate JEP 390 In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - [JDK-8252180](https://bugs.openjdk.java.net/browse/JDK-8252180): Deprecate wrapper class constructors for removal (rriggs) > - [JDK-8254047](https://bugs.openjdk.java.net/browse/JDK-8254047): Revise "value-based class" & apply to wrappers (dlsmith) > - [JDK-8252181](https://bugs.openjdk.java.net/browse/JDK-8252181):Define & apply annotation jdk.internal.ValueBased (rriggs) > - [JDK-8252183](https://bugs.openjdk.java.net/browse/JDK-8252183): Add 'lint' warning for @ValueBased classes (sadayapalam) > - [JDK-8257027](https://bugs.openjdk.java.net/browse/JDK-8257027): Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1636 From darcy at openjdk.java.net Tue Dec 8 22:15:35 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 22:15:35 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == In-Reply-To: <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com> References: <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com> Message-ID: On Tue, 8 Dec 2020 17:59:41 GMT, Stuart Marks wrote: >> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. >> >> Once the wording is worked out, I'll replicate it for the analogous methods on Float. > > I'll note initially that the original bug is about `equals` and `==` whereas this change also covers `compareTo` and additional comparison operators `<` and `>`. I believe covering this additional material **IS** important, as these concepts are all closely related. > > While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice. > > (One additional concept that ought to be covered is that `compareTo` is *consistent with equals*. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.) > > I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in `Double`. The various methods can then make some terse assertions and then refer to the combined explanation. `Float` could refer to `Double` instead of replicating the text. > > Another alternative is to put this explanation into the `java.lang` package specification. This might be a good fit, since there is already some explanation there of the boxed primitives. > > > I'll note initially that the original bug is about `equals` and `==` whereas this change also covers `compareTo` and additional comparison operators `<` and `>`. I believe covering this additional material **IS** important, as these concepts are all closely related. > > While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice. > > (One additional concept that ought to be covered is that `compareTo` is _consistent with equals_. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.) > > I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in `Double`. The various methods can then make some terse assertions and then refer to the combined explanation. `Float` could refer to `Double` instead of replicating the text. > > Another alternative is to put this explanation into the `java.lang` package specification. This might be a good fit, since there is already some explanation there of the boxed primitives. I added discussion of compareTo as well as equals to the scope of the bug since they are sibling surprising deviations from what is expected and have the same root cause. (I took care to say "incomplete order" rather than "partial order" since a partial order requires reflexivity.) The interface java.lang.Comparable gives a definition of "consistent with equals." I didn't verify it doesn't have an anchor to link to, but we don't typically link to the definition. However, I wouldn't be adverse to having "consistent with equals" link to Comparable; that would be more obvious than expecting the reader to follow the "Specified by: compareTo in interface Comparable" link javadoc generates for the method. I think the Float and Double equals and compareTo methods should at least get pointers to any new section added -- I think a standalone section in the package javadoc by itself would have low discoverability. I'm make another iteration over the text; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1699 From mr at openjdk.java.net Tue Dec 8 22:15:40 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Tue, 8 Dec 2020 22:15:40 GMT Subject: Integrated: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:49:30 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. This pull request has now been integrated. Changeset: ed4c4ee7 Author: Mark Reinhold URL: https://git.openjdk.java.net/jdk/commit/ed4c4ee7 Stats: 162 lines in 5 files changed: 24 ins; 73 del; 65 mod 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default Co-authored-by: Alan Bateman Reviewed-by: mchung, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From dholmes at openjdk.java.net Tue Dec 8 22:38:37 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Dec 2020 22:38:37 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v5] In-Reply-To: References: Message-ID: <6zD-WD76gZaXzeOuaj0c1N75lPbLTxUOHoLu9M4ZbLc=.367ab8af-b105-4977-afe1-0a29bbe2d88a@github.com> On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'master' into JDK-8257450 > - Update symbol files for JDK 16b27. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - JDK-8257450 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/d1c29ce3...ff9b78ec Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From mchung at openjdk.java.net Tue Dec 8 22:57:39 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Dec 2020 22:57:39 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes Message-ID: This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with Record attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. ------------- Commit messages: - 8257596: Clarify trusted final fields for record classes Changes: https://git.openjdk.java.net/jdk/pull/1706/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1706&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257596 Stats: 60 lines in 4 files changed: 30 ins; 10 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1706/head:pull/1706 PR: https://git.openjdk.java.net/jdk/pull/1706 From dlsmith at openjdk.java.net Tue Dec 8 23:07:35 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 8 Dec 2020 23:07:35 GMT Subject: Integrated: 8257845: Integrate JEP 390 In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com> Message-ID: On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - [JDK-8252180](https://bugs.openjdk.java.net/browse/JDK-8252180): Deprecate wrapper class constructors for removal (rriggs) > - [JDK-8254047](https://bugs.openjdk.java.net/browse/JDK-8254047): Revise "value-based class" & apply to wrappers (dlsmith) > - [JDK-8252181](https://bugs.openjdk.java.net/browse/JDK-8252181):Define & apply annotation jdk.internal.ValueBased (rriggs) > - [JDK-8252183](https://bugs.openjdk.java.net/browse/JDK-8252183): Add 'lint' warning for @ValueBased classes (sadayapalam) > - [JDK-8257027](https://bugs.openjdk.java.net/browse/JDK-8257027): Diagnose synchronization on @ValueBased classes (lfoltan) > > All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.) > > CSRs have also been completed or are nearly complete: > > - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation > - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class" > - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings > > Here's an overview of the files changed: > > - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes. > > - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance. > > - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`. > > - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation. > > - `src/java.management.rmi`: removing uses of wrapper class constructors. > > - `src/java.xml`: removing uses of wrapper class constructors. > > - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`. > > - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.) > > - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests > > - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics > > - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`. This pull request has now been integrated. Changeset: 48d8650a Author: Dan Smith URL: https://git.openjdk.java.net/jdk/commit/48d8650a Stats: 902 lines in 114 files changed: 489 ins; 121 del; 292 mod 8257845: Integrate JEP 390 8254047: [JEP 390] Revise "value-based class" & apply to wrappers 8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased 8252183: [JEP 390] Add 'lint' warning for @ValueBased classes 8257027: [JEP 390] Diagnose synchronization on @ValueBased classes 8252180: [JEP 390] Deprecate wrapper class constructors for removal Co-authored-by: Roger Riggs Co-authored-by: Srikanth Adayapalam Co-authored-by: Lois Foltan Reviewed-by: rriggs, hseigel, mchung, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/1636 From darcy at openjdk.java.net Tue Dec 8 23:23:55 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Dec 2020 23:23:55 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v6] In-Reply-To: References: Message-ID: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com> > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Get in JEP 390 changes. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update symbol files for JDK 16b27. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update tests. - Merge branch 'master' into JDK-8257450 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/823053e1...57ba7b64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/ff9b78ec..57ba7b64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=04-05 Stats: 1178 lines in 148 files changed: 571 ins; 195 del; 412 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From almatvee at openjdk.java.net Tue Dec 8 23:24:42 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 8 Dec 2020 23:24:42 GMT Subject: RFR: 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways Message-ID: This is similar issue we used to have for hdiutil create/detach, but for "convert". Added same workaround to repeat command. I also added repeat for "udifrez" command just in case. ------------- Commit messages: - 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways Changes: https://git.openjdk.java.net/jdk/pull/1687/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1687&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238781 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1687/head:pull/1687 PR: https://git.openjdk.java.net/jdk/pull/1687 From forax at univ-mlv.fr Tue Dec 8 23:42:33 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 9 Dec 2020 00:42:33 +0100 (CET) Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: <2082129525.1697377.1607470953452.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mandy Chung" > ?: "core-libs-dev" , "hotspot-dev" > Envoy?: Mardi 8 D?cembre 2020 23:57:39 > Objet: RFR: 8257596: Clarify trusted final fields for record classes Hi Mandy, > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on > classes with Record attributes. That introduces a regression in > `InstanceKlass::is_record` that returns true on a non-record class which has > `RecordComponents` attribute present. This causes unexpected semantics in > `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust > final fields for non-record classes. It's not an issue, the JVM view of what a record is and the JLS view of what a record is doesn't have to be identical, only aligned. It's fine for the VM to consider any class that have a record Attribute is a record. We already had this discussion on amber-spec-expert list, see https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html We already know that the JLS definition of a record will have to be changed for inline record (an inline record is not direct subclass of j.l.Record because you have the reference projection in the middle). The real issue is that the JIT optimisation and Field.set() should be aligned, VarHandle deosn't let you change a final field and Unsafe is unsafe, so the current problem is that Field.set() relies on the reflection api by calling Class.isRecord() which is not good because Classs.isRecord() returns the JLS view of the world not the JVM view of the world. As said in the mail chain above, for the JIT optimization, instead of listing all the new constructs, record, inline, etc, i propose to check the other way, only allow to set a final field is only allowed for plain old java class, so the VM should not have a method InstanceKlass::is_record but a method that return if a class is a plain class or not and this method should be called by the JIT and by Field.set (through a JVM entry point) so the fact the optimization will be done or not is not related to what the JLS think a record is, those are separated concern. The more we inject the Java (the language) semantics in the JVM the less it is useful for other languages that run one the JVM. R?mi > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a > record class, i.e. final direct subclass of `java.lang.Record` with the > presence of `RecordComponents` attribute. There is no change to JVM class file > validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and > direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if > `RecordComponents` attribute is present; otherwise, returns NULL. This does > not check if it's a record class or not. So it may return non-null on a > non-record class if it has `RecordComponents` attribute. So > `JVM_GetRecordComponents` returns the content of the classfile. R?mi > > ------------- > > Commit messages: > - 8257596: Clarify trusted final fields for record classes > > Changes: https://git.openjdk.java.net/jdk/pull/1706/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1706&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8257596 > Stats: 60 lines in 4 files changed: 30 ins; 10 del; 20 mod > Patch: https://git.openjdk.java.net/jdk/pull/1706.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1706/head:pull/1706 > > PR: https://git.openjdk.java.net/jdk/pull/1706 From redestad at openjdk.java.net Tue Dec 8 23:57:35 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 23:57:35 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:54:41 GMT, Aleksey Shipilev wrote: > See here: > https://github.com/mcimadamore/jdk/runs/1460615378 > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java > > STDERR: > Invalid maximum heap size: -Xmx4G > The specified size exceeds the maximum representable size. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. > > Additional testing: > - [x] Affected test on Linux x86_32 (skipped now) > - [x] Affected test on Linux x86_64 (still passes) Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From mandy.chung at oracle.com Wed Dec 9 00:16:52 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Dec 2020 16:16:52 -0800 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> Message-ID: <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com> On 12/8/20 5:07 AM, Johannes Kuhn wrote: > On 08-Dec-20 5:40, Mandy Chung wrote: >> Thanks David.? I was about to create one. >> >> This is indeed a gap in injecting this trampoline class for >> supporting @CallerSensitive methods.? The InjectedInvoker ensures >> that the InjectedInvoker class has the same class loader as the >> lookup class.? W.r.t. your patch, it seems okay but I have to >> consider and think through the security implication carefully. >> >> You mentioned "Some old software loves to set static final fields >> through reflection" - can you share some example libraries about >> this??? This is really ugly hack!! >> >> Mandy > > Not sure if I read this correctly as "please share some example of > code that tries to do that" or "please share code that you write to > fix that". > So I do both. > I was curious to find out what old software attempts to change static final fields via reflection and why they do that.?? This leads to various unpredictable issues.?? Looks like you want to get old software to work and have to hack their static final fields!! > Setting static final fields does not work [1]. It probably never > really did. It usually seems to work - but there is no guarantee that > it actually does (like undefined behavior). Field::setXXX will throw IAE on static final fields and non-static fields declared on a record or hidden class too. > > JPEXS [2] for example used that for it's configuration. > Also some old Minecraft Forge version (a Minecraft mod loader / mod > API) depends on this. Example use [3], but they do really ugly things. > > So, I said I develop agents to get old stuff running on a current Java > version. > Why? Fun, I guess. I also learn a lot a about what are the main > comparability problems with newer Java versions. > Pros of writing an agent: > * I don't need the source code. > * I don't need to setup a build environment with all dependencies, > lombok and who knows what else is required. > In all, it's faster for me. And I then have a list of problems - and > how they can be solved. I did publish my JPESX agent here [4]. > But yeah, it's an ugly hack. > > For the nestmate security consideration, the following invariants > should already hold: > * To call a @CallerSensitive method, the Lookup needs to have full > privilege access (Lookup.hasFullPrivilegeAccess()) > -> Injected Invokers are only created for full privilege lookups. > * The injected invoker is in the same runtime package and has the same > protection domain. > * It is already possible to obtain a Lookup for the injected invoker > by calling MethodHandles.lookup() through a MethodHandle (yikes) [5]. I am concerned with this.? I am inclined to say we need to fix JDK-8013527 if we fix this issue. > > This means, we only have to consider what additional privileges the > injected invoker gets if it is also a nestmate of the lookup class. > I don't see any problem with that, as you already have a full > privilege lookup when the injected invoker is created. > > - Johannes > > PS.: JDK-8013527 is mildly related - as the @CallerSensitive methods > in java.lang.reflect are "hyper-sensitive". This fix will get JDK-8013527 passed the IAE but the lookup class of the resulting Lookup object is the hidden class which is still incorrect. Mandy > > [1]: > https://urldefense.com/v3/__https://gist.github.com/DasBrain/25c6738610c517ee375aacc86ffebd0c__;!!GqivPVa7Brio!IRaER_1fNHPfhaN4erhar7ZMzL5yVGyoWGcH2FS_SMH23wknQghpz2amisGRByQ4Yg$ > [2]: > https://urldefense.com/v3/__https://github.com/akx/jpexs-decompiler/blob/6c998254b9d5bdce80be1b92d34836820ee31a1d/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/configuration/Configuration.java*L869__;Iw!!GqivPVa7Brio!IRaER_1fNHPfhaN4erhar7ZMzL5yVGyoWGcH2FS_SMH23wknQghpz2amisHSLG47fg$ > [3]: > https://urldefense.com/v3/__https://github.com/Chisel-Team/Chisel/blob/1.12/dev/src/main/java/team/chisel/common/init/ChiselBlocks.java*L18__;Iw!!GqivPVa7Brio!IRaER_1fNHPfhaN4erhar7ZMzL5yVGyoWGcH2FS_SMH23wknQghpz2amisHY5Ta7RQ$ > [4]: > https://urldefense.com/v3/__https://github.com/DasBrain/jpex/tree/master/src/pw/dasbrain/jpexs/agent__;!!GqivPVa7Brio!IRaER_1fNHPfhaN4erhar7ZMzL5yVGyoWGcH2FS_SMH23wknQghpz2amisEYiprE4w$ > [5]: > https://urldefense.com/v3/__https://gist.github.com/DasBrain/142cb8ef9cc16e7469ac519790119e07__;!!GqivPVa7Brio!IRaER_1fNHPfhaN4erhar7ZMzL5yVGyoWGcH2FS_SMH23wknQghpz2amisEC0fauqw$ > From psandoz at openjdk.java.net Wed Dec 9 00:35:37 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Dec 2020 00:35:37 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks wrote: >> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: >> >> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! >> >> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. >> >> Separately, I'll work on retrofitting various call sites around the JDK to use this method. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > fix typo, clarify asserts disabled, test prefGrowth==0 Marked as reviewed by psandoz (Reviewer). src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 616: > 614: * greater than the soft maximum but does not exceed Integer.MAX_VALUE, the minimum > 615: * required length is returned. Otherwise, the minimum required length exceeds > 616: * Integer.MAX_VALUE, which can never be fulfilled, so this method throws OutOfMemoryError. I think you can simplify with: Suggestion: * If the preferred length exceeds the soft maximum, we use the minimum growth * amount. The minimum required length is determined by adding the minimum growth * amount to the current length. * If the minimum required length exceeds Integer.MAX_VALUE, then this method * throws OutOfMemoryError. Otherwise, this method returns the soft maximum or * minimum required length, which ever is greater. Then i think it follows that `Math.max` can be used in the implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From mchung at openjdk.java.net Wed Dec 9 00:43:34 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Dec 2020 00:43:34 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with Record attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Hi Remi, > It's not an issue, the JVM view of what a record is and the JLS view of what a record is doesn't have to be identical, > only aligned. It's fine for the VM to consider any class that have a record Attribute is a record. > > We already had this discussion on amber-spec-expert list, > see https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html What is the conclusion (sorry it was unclear to me)? Drop TNSFF for records? This issue is to fix the regression introduced by JDK-8255342. I expect someone else will file a new JBS issue and implement what amber-spec-experts decided. > We already know that the JLS definition of a record will have to be changed for inline record (an inline record is not direct subclass of j.l.Record because you have the reference projection in the middle). Yes I saw that. I updated [JDK-8251041](https://bugs.openjdk.java.net/browse/JDK-8251041) to follow up. > The real issue is that the JIT optimisation and Field.set() should be aligned, VarHandle deosn't let you change a final field and Unsafe is unsafe, so the current problem is that Field.set() relies on the reflection api by calling Class.isRecord() which is not good because Classs.isRecord() returns the JLS view of the world not the JVM view of the world. > > As said in the mail chain above, for the JIT optimization, instead of listing all the new constructs, record, inline, etc, i propose to check the other way, only allow to set a final field is only allowed for plain old java class, so the VM should not have a method InstanceKlass::is_record but a method that return if a class is a plain class or not and this method should be called by the JIT and by Field.set (through a JVM entry point) > so the fact the optimization will be done or not is not related to what the JLS think a record is, those are separated concern. I agree the current situation is not ideal which requires to declare all the new constructs explicitly for TNSFF. However, it's a reasonable tradeoff to get the JIT optimization for records in time while waiting for true TNSFF investigation like JMM and other relevant specs. I see this just a stop-gap solution. When the long-term TNSFF is in place, the spec can be updated to drop the explicit list of record, inline, etc. A related issue is [JDK-8233873](https://bugs.openjdk.java.net/browse/JDK-8233873). I'm happy if we can do TNSFF in a different solution. Again this PR intends to fix the regression. Two options: 1. Keep [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) and implement as this proposed patch 2. Backout [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) I expect Chris and/or others will follow up the decision made by the amber-spec-experts w.r.t. trusting finals in records. I'm okay with either option. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From info at j-kuhn.de Wed Dec 9 02:02:38 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Wed, 9 Dec 2020 03:02:38 +0100 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com> References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com> Message-ID: On 09-Dec-20 1:16, Mandy Chung wrote: > On 12/8/20 5:07 AM, Johannes Kuhn wrote: >> >> Not sure if I read this correctly as "please share some example of >> code that tries to do that" or "please share code that you write to >> fix that". >> So I do both. >> > > I was curious to find out what old software attempts to change static > final fields via reflection and why they do that.?? This leads to > various unpredictable issues.?? Looks like you want to get old > software to work and have to hack their static final fields!! Just do a quick search for "NoSuchFieldException modifiers". A lot of code does it, my impression is that often someone tried to be clever - just because they can. > >> Setting static final fields does not work [1]. It probably never >> really did. It usually seems to work - but there is no guarantee that >> it actually does (like undefined behavior). > > Field::setXXX will throw IAE on static final fields and non-static > fields declared on a record or hidden class too. The example works with Java 8 and 11 - it "tricks" the JIT into constant folding a static final field, so the subsequent change is not reflected. > >> For the nestmate security consideration, the following invariants >> should already hold: >> * To call a @CallerSensitive method, the Lookup needs to have full >> privilege access (Lookup.hasFullPrivilegeAccess()) >> -> Injected Invokers are only created for full privilege lookups. >> * The injected invoker is in the same runtime package and has the >> same protection domain. >> * It is already possible to obtain a Lookup for the injected invoker >> by calling MethodHandles.lookup() through a MethodHandle (yikes) [5]. > > I am concerned with this.? I am inclined to say we need to fix > JDK-8013527 if we fix this issue. > >> >> This means, we only have to consider what additional privileges the >> injected invoker gets if it is also a nestmate of the lookup class. >> I don't see any problem with that, as you already have a full >> privilege lookup when the injected invoker is created. >> >> - Johannes >> >> PS.: JDK-8013527 is mildly related - as the @CallerSensitive methods >> in java.lang.reflect are "hyper-sensitive". > > This fix will get JDK-8013527 passed the IAE but the lookup class of > the resulting Lookup object is the hidden class which is still incorrect. > > Mandy A quick history about JDK-8013527 (and JDK-8207834 - which has the same root cause, but I wrote an comment on that): In Java 8, the injected invoker class had a name starting with "java.lang.invoke.". Creating a lookup for a class that starts with that name or binding the caller for such a class is explicitly blocked. In Java 9 the name of the injected invoker has changed - from this point on, the name of the injected invoker did depend on the package of the lookup class / caller. **It is already possible** to obtain a Lookup for the injected invoker by calling MethodHandles.lookup() through a MethodHandle. It doesn't throw an IAE anymore. **Since Java 9.** There are a lot of things to consider when trying to fix JDK-8013527. The first problem is: How do you determine the original class? It doesn't work with just using the nest host - as this might be different from the original class. Using the name might also not work - as the original class could be a hidden class itself. So, the only real solution is to attach that information (a reference to the lookup class) to the injected invoker. Then we have to detect that the target class is an injected invoker - and replace it with the actual lookup class. And this comes with some cost - either the job is done by Reflection.getCallerClass() - which would fix any other problem of that kind - or any hyper-sensitive @CallerSensitive method has to do this on it's own. (Luckily there are only a handful @CallerSensitive methods - and only a few are hyper-sensitive.) Unfortunately, I don't know enough about hotspot to determine if it is possible to change the "owner class" of some code. Also, garbage collection... I don't know enough about those systems. I only look at the stuff from the Java / bytecode side. In the end, I'm not sure if fixing l.lookupClass() == ((Lookup) l.findStatic(MethodHandles.class, "lookup", MethodType.methodType(Lookup.class)).invokeExact()).lookupClass() is worth that effort. - Johannes From shade at openjdk.java.net Wed Dec 9 06:45:39 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 9 Dec 2020 06:45:39 GMT Subject: Integrated: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:54:41 GMT, Aleksey Shipilev wrote: > See here: > https://github.com/mcimadamore/jdk/runs/1460615378 > > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java > > STDERR: > Invalid maximum heap size: -Xmx4G > The specified size exceeds the maximum representable size. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. > > Additional testing: > - [x] Affected test on Linux x86_32 (skipped now) > - [x] Affected test on Linux x86_64 (still passes) This pull request has now been integrated. Changeset: 9ce3d806 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9ce3d806 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 Reviewed-by: jiefu, adityam, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From alanb at openjdk.java.net Wed Dec 9 07:37:37 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Dec 2020 07:37:37 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 20:42:52 GMT, Mandy Chung wrote: >> `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. >> >> This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > improve the deprecation message per feedback Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1684 From alanb at openjdk.java.net Wed Dec 9 07:39:37 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Dec 2020 07:39:37 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 21:15:48 GMT, Martin Buchholz wrote: >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > JDK-8234131 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From almatvee at openjdk.java.net Wed Dec 9 08:10:46 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Dec 2020 08:10:46 GMT Subject: RFR: 8257924: Use full path when running external executable from jpackage Message-ID: Changed all external executables to run via full path to avoid potential issues. ------------- Commit messages: - 8257924: Use full path when running external executable from jpackage Changes: https://git.openjdk.java.net/jdk/pull/1710/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1710&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257924 Stats: 22 lines in 9 files changed: 1 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1710.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1710/head:pull/1710 PR: https://git.openjdk.java.net/jdk/pull/1710 From ngasson at openjdk.java.net Wed Dec 9 08:25:43 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 9 Dec 2020 08:25:43 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 Message-ID: This is more-or-less a straight port of the x86 code to AArch64. GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() to generate a blob that jumps to the native function entry point. This simply switches the thread state from Java to native and handles the safepoint poll on return from native code. AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame pointer) may hold a live oop over the MachCallNative node. Normally this would be saved by RegisterSaver::save_live_registers() but the native invoker blob is not a "proper" stub routine so doesn't have an oop map. I copied the x86 solution to this where the frame pointer register is saved to the stack and a pointer to that is stored in the frame anchor. This is then read back and added to the register map when walking the stack. I saw in the PR comments [1] that this might be a temporary fix, but I'm not sure if there's any plan to change that now? Another potential fix might be to change the C2 register definition of R29 and R29_H to be save-on-call as below. This works for the TestStackWalk.java test case but I don't know whether it has other unintended side-effects. reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); JMH results from jdk/incubator/foreign/CallOverhead.java to show it's working: -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: Benchmark Mode Cnt Score Error Units CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: Benchmark Mode Cnt Score Error Units CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 ------------- Commit messages: - 8257882: Implement linkToNative intrinsic on AArch64 Changes: https://git.openjdk.java.net/jdk/pull/1711/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257882 Stats: 234 lines in 8 files changed: 227 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1711/head:pull/1711 PR: https://git.openjdk.java.net/jdk/pull/1711 From alanb at openjdk.java.net Wed Dec 9 09:12:39 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Dec 2020 09:12:39 GMT Subject: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 05:54:24 GMT, Martin Buchholz wrote: >> 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates > > Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1645 From jboes at openjdk.java.net Wed Dec 9 09:35:37 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 9 Dec 2020 09:35:37 GMT Subject: Integrated: 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 17:31:34 GMT, Julia Boes wrote: > This change applies a stricter semantic distinction of 'type' versus 'class and interface'. This is based on the JLS changes described in the "Consistent Class and Interface Terminology" document: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html. > > The following rules were applied: > - 'class' and/or 'interface' are used when referring to the class/interface itself > - 'type' is used when referring to the type of a variable or expression This pull request has now been integrated. Changeset: 5bdce9b9 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/5bdce9b9 Stats: 24 lines in 2 files changed: 0 ins; 0 del; 24 mod 8257639: Update usage of "type" terminology in java.lang.Enum & java.lang.Record Reviewed-by: chegar, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/1670 From isipka at openjdk.java.net Wed Dec 9 10:31:33 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 9 Dec 2020 10:31:33 GMT Subject: Integrated: 8257516: define test group for manual tests In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 16:13:59 GMT, Ivan ?ipka wrote: > Defined new test groups as defined in ticket. @fguallini This pull request has now been integrated. Changeset: 616b1f12 Author: Ivan ?ipka Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/616b1f12 Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod 8257516: define test group for manual tests Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/1416 From aph at openjdk.java.net Wed Dec 9 10:52:37 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 9 Dec 2020 10:52:37 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 08:20:38 GMT, Nick Gasson wrote: > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 src/hotspot/cpu/aarch64/aarch64.ad line 16057: > 16055: > 16056: format %{ "CALL, native $meth" %} > 16057: It might be better to expand this a little to indicate a near or a far call, if that's possible. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3156: > 3154: > 3155: // Store a pointer to the previous R29 saved on the stack as it may > 3156: // contain an oop if PreserveFramePointer is off. This value is This is a bit confusing: please say "R29 (RFP)" here. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3186: > 3184: // Make sure that native code does not change SVE vector length. > 3185: __ verify_sve_vector_length(); > 3186: } Do we have to surround every call to verify_sve_vector_length() with if (UseSVE > 0) ? Why is that check not inside verify_sve_vector_length() ? What is the meaning of the > 0 comparison? Can it be negative? So many questions. :-) src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3227: > 3225: __ mov(c_rarg0, rthread); > 3226: #ifndef PRODUCT > 3227: assert(frame::arg_reg_save_area_bytes == 0, "not expecting frame reg save area"); I don't think we need #ifndef PRODUCT here. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3098: > 3096: MacroAssembler* masm = _masm; > 3097: if (reg->is_Register()) { > 3098: __ push(RegSet::of(reg->as_Register()), sp); Is this right? SP is 16-aligned, so this will use 16 bytes of stack for every 8-byte register. Does it get used a lot? ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From github.com+20868526+mikeedgar at openjdk.java.net Wed Dec 9 11:27:46 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Wed, 9 Dec 2020 11:27:46 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v3] In-Reply-To: References: Message-ID: > Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. > > Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). Michael Edgar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Correct comments/annotations - Update XML stream filter test and comments - Update JavaDoc code comment, move unit test class - Update test for jtreg - 8255918: Throw XMLStreamExceptions from XMLStreamFilterImpl constructor ------------- Changes: https://git.openjdk.java.net/jdk/pull/1209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=02 Stats: 103 lines in 2 files changed: 91 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1209/head:pull/1209 PR: https://git.openjdk.java.net/jdk/pull/1209 From github.com+20868526+mikeedgar at openjdk.java.net Wed Dec 9 11:38:35 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Wed, 9 Dec 2020 11:38:35 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v3] In-Reply-To: <1KM_AqbgbZjaQefWH0ghLKcHPi9nVEgJwHDU7IHBY3M=.55315160-9d6d-4613-8028-235fce61fd23@github.com> References: <1KM_AqbgbZjaQefWH0ghLKcHPi9nVEgJwHDU7IHBY3M=.55315160-9d6d-4613-8028-235fce61fd23@github.com> Message-ID: <8t3Cu9sIYbyDVYFGzcZRyQfPJPXgEM3brjHCa2oZsEA=.7e9e3732-40ce-407b-95ce-2ee6c34a87c6@github.com> On Mon, 7 Dec 2020 17:58:09 GMT, Joe Wang wrote: >> Michael Edgar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Correct comments/annotations >> - Update XML stream filter test and comments >> - Update JavaDoc code comment, move unit test class >> - Update test for jtreg >> - 8255918: Throw XMLStreamExceptions from XMLStreamFilterImpl constructor > > I left comments the other day but forgot to submit. I've adjusted them based on your new changes. @JoeWang-Java - I believe I have addressed all of your comments. The branch has also been re-based on the `master` branch. Please let me know if any additional changes are needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From github.com+20868526+mikeedgar at openjdk.java.net Wed Dec 9 11:49:51 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Wed, 9 Dec 2020 11:49:51 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v4] In-Reply-To: References: Message-ID: > Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. > > Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). Michael Edgar has updated the pull request incrementally with one additional commit since the last revision: Additional test class clean-up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1209/files - new: https://git.openjdk.java.net/jdk/pull/1209/files/275ea830..a416b276 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1209/head:pull/1209 PR: https://git.openjdk.java.net/jdk/pull/1209 From isipka at openjdk.java.net Wed Dec 9 12:28:39 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 9 Dec 2020 12:28:39 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v2] In-Reply-To: References: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> Message-ID: On Thu, 3 Dec 2020 14:14:22 GMT, Sean Mullan wrote: >> Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8166026: Refactor java/lang shell tests to java >> - 8166026: Refactor java/lang shell tests to java > > Marked as reviewed by mullan (Reviewer). @iignatev could you please sponsor this? Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/1579 From tschatzl at openjdk.java.net Wed Dec 9 13:25:33 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 13:25:33 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: <2TbNnDlF1nuEFWLddNG3wdj5EL0gg-1hzGwe2-emoQE=.e950f0f7-6be0-426d-8634-bc3c3175030a@github.com> References: <2TbNnDlF1nuEFWLddNG3wdj5EL0gg-1hzGwe2-emoQE=.e950f0f7-6be0-426d-8634-bc3c3175030a@github.com> Message-ID: On Tue, 8 Dec 2020 17:30:11 GMT, Mandy Chung wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java >> jdk/java/lang/ref/ReferenceEnqueue.java >> >> In each of them, some combination of using Reference.refersTo and >> ReferenceQueue.remove with a timeout were used to eliminate the use of >> Reference.isEnqueued. >> >> I also cleaned up ReferencesGC.java in various respects. It contained >> several bits of dead code, and the failure checks were made stronger. >> >> Testing: >> mach5 tier1 >> Locally (linux-x64) ran all three tests with each GC (including Shenandoah). > > Marked as reviewed by mchung (Reviewer). I'm not able to put this in the appropriate place using the github UI: [pre-existing] The topWeakReferenceGC.java description at the top describes that the test calls System.gc() explicitly to trigger garbage collections at the end. It does not. Maybe this could be weasel-worded around like in the other cases in that text. ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From ihse at openjdk.java.net Wed Dec 9 13:31:39 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 9 Dec 2020 13:31:39 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. >From a build PoV this sounds like a reasonable fix, but you need a review from someone in core-libs as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From tschatzl at openjdk.java.net Wed Dec 9 13:31:41 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 13:31:41 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote: > Please review this change that eliminates the use of Reference.isEnqueued by > tests. There were three tests using it: > > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java > jdk/java/lang/ref/ReferenceEnqueue.java > > In each of them, some combination of using Reference.refersTo and > ReferenceQueue.remove with a timeout were used to eliminate the use of > Reference.isEnqueued. > > I also cleaned up ReferencesGC.java in various respects. It contained > several bits of dead code, and the failure checks were made stronger. > > Testing: > mach5 tier1 > Locally (linux-x64) ran all three tests with each GC (including Shenandoah). Changes requested by tschatzl (Reviewer). test/jdk/java/lang/ref/ReferenceEnqueue.java line 58: > 56: for (int i = 0; i < iterations; i++) { > 57: System.gc(); > 58: enqueued = (queue.remove(100) == ref); The code does not catch `InterruptedException` like it does in the other files. test/hotspot/jtreg/vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java line 129: > 127: } > 128: > 129: int REMOVE = (int) (RANGE * RATIO); These two constants could be factored out as static finals to match the casing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From ihse at openjdk.java.net Wed Dec 9 13:32:43 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 9 Dec 2020 13:32:43 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v12] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:35:03 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: > > - Merging recent master changes into JDK-8250768 > - Fixing navigator for the PREVIEW page. > - Fixing typo. > - Removing obsolette @PreviewFeature. > - Merging master into JDK-8250768 > - Removing unnecessary property keys. > - Cleanup - removing unnecessary code. > - Merging master into JDK-8250768-dev4 > - Reflecting review comments. > - Removing trailing whitespace. > - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57 Build changes still good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From ihse at openjdk.java.net Wed Dec 9 13:46:39 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 9 Dec 2020 13:46:39 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v6] In-Reply-To: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com> References: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com> Message-ID: <4lA_pBO9zyK3YLajvxRTMaSpzXaTmeieeakdjmoRx_0=.1dbcf13e-809f-432b-ad71-8b9bd9afb9d7@github.com> On Tue, 8 Dec 2020 23:23:55 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - Get in JEP 390 changes. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Update symbol files for JDK 16b27. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Merge branch 'master' into JDK-8257450 > - Update tests. > - Merge branch 'master' into JDK-8257450 > - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/5c27251d...57ba7b64 Build changes (or should I say "change"?) looks good! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1531 From tschatzl at openjdk.java.net Wed Dec 9 14:01:35 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 14:01:35 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 13:23:47 GMT, Thomas Schatzl wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java >> jdk/java/lang/ref/ReferenceEnqueue.java >> >> In each of them, some combination of using Reference.refersTo and >> ReferenceQueue.remove with a timeout were used to eliminate the use of >> Reference.isEnqueued. >> >> I also cleaned up ReferencesGC.java in various respects. It contained >> several bits of dead code, and the failure checks were made stronger. >> >> Testing: >> mach5 tier1 >> Locally (linux-x64) ran all three tests with each GC (including Shenandoah). > > test/jdk/java/lang/ref/ReferenceEnqueue.java line 58: > >> 56: for (int i = 0; i < iterations; i++) { >> 57: System.gc(); >> 58: enqueued = (queue.remove(100) == ref); > > The code does not catch `InterruptedException` like it does in the other files. I understand that the test code previously just forwarded the `InterruptedException` if it happened in the `Thread.sleep()` call too. So this may only be an exiting issue and please ignore this comment. Not catching `InterruptedException` here only seems to be a cause for unnecessary failure. Then again, it probably does not happen a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From rriggs at openjdk.java.net Wed Dec 9 14:28:33 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 9 Dec 2020 14:28:33 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. Looks ok to me. But it would be good if @prrace can have a look. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1569 From kbarrett at openjdk.java.net Wed Dec 9 14:38:34 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 14:38:34 GMT Subject: RFR: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 20:42:52 GMT, Mandy Chung wrote: >> `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. >> >> This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > improve the deprecation message per feedback Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1684 From jlahoda at openjdk.java.net Wed Dec 9 15:10:07 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Dec 2020 15:10:07 GMT Subject: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v6] In-Reply-To: References: Message-ID: <0GbDxAutpYeJtWyAb4zDfywKH5y0Nur6zkOLqfCUTlA=.e522e1b8-cdda-4598-9129-a1935bccd276@github.com> > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Need to open a few packages for the test. - Merge branch 'master' into JDK-8256950 - Blank lines do not count for the text block indentation, removing them. - Reflecting review comments. - Fixing tests on Windows - normalizing line endings. - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950 - Update CreateSymbolsTest.java - CreateSymbols should support records with no components. - Cleaning TODO. - Cleaning TODO. - ... and 3 more: https://git.openjdk.java.net/jdk/compare/51dfede0...08d7a106 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1480/files - new: https://git.openjdk.java.net/jdk/pull/1480/files/3aaaf28c..08d7a106 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=04-05 Stats: 41234 lines in 1081 files changed: 28666 ins; 7705 del; 4863 mod Patch: https://git.openjdk.java.net/jdk/pull/1480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480 PR: https://git.openjdk.java.net/jdk/pull/1480 From jlahoda at openjdk.java.net Wed Dec 9 15:10:08 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Dec 2020 15:10:08 GMT Subject: Integrated: JDK-8256950: Add record attribute support to symbol generator CreateSymbols In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda wrote: > Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run them. > -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway). > -fixing the -Xprint annotation processor to print record component annotations. > > Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works. This pull request has now been integrated. Changeset: 6eff9315 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/6eff9315 Stats: 1961 lines in 12 files changed: 1198 ins; 745 del; 18 mod 8256950: Add record attribute support to symbol generator CreateSymbols Reviewed-by: jjg, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1480 From isipka at openjdk.java.net Wed Dec 9 15:19:58 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 9 Dec 2020 15:19:58 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v3] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/3a832a4d..fc0af133 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=01-02 Stats: 14 lines in 1 file changed: 2 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From rriggs at openjdk.java.net Wed Dec 9 16:46:54 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 9 Dec 2020 16:46:54 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v19] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarified parsing of hex as unsigned in fromHexDigits methods. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/af7b1fa9..044d4633 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=17-18 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From rriggs at openjdk.java.net Wed Dec 9 17:27:38 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 9 Dec 2020 17:27:38 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v3] In-Reply-To: References: Message-ID: <4NqPrRAc0Nd5LuQRbHNaDl4WVmBnaCvnyXTE-lKS9iY=.c40d25d1-78d1-40f9-93a6-efced1ccedf2@github.com> On Wed, 9 Dec 2020 15:19:58 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From mchung at openjdk.java.net Wed Dec 9 18:26:40 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Dec 2020 18:26:40 GMT Subject: Integrated: 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 02:36:01 GMT, Mandy Chung wrote: > `Reference::isEnqueued` method was never implemented as it was initially specified since 1.2. The specification says that it tests if this reference object has been enqueued, but the long-standing behavior is to test if this reference object is in its associated queue, only reflecting the state at the time when this method is executed. The implementation doesn't do what the specification promised, which might cause serious bugs if unnoticed. For example, an application that relies on this method to release critical resources could cause serious performance issues, in particular when this method is misused on Reference objects without an associated queue. `Reference::refersTo(null)` is the better recommended way to test if a Reference object has been cleared. > > This proposes to deprecate `Reference::isEnqueued`. Also the spec is updated to match the long-standing behavior. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8189386 This pull request has now been integrated. Changeset: 5f033412 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/5f033412 Stats: 28 lines in 2 files changed: 22 ins; 0 del; 6 mod 8052260: Reference.isEnqueued() spec does not match the long-standing behavior returning true iff it's in the ref queue Reviewed-by: kbarrett, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1684 From herrick at openjdk.java.net Wed Dec 9 18:26:45 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 9 Dec 2020 18:26:45 GMT Subject: RFR: 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 07:45:30 GMT, Alexander Matveev wrote: > This is similar issue we used to have for hdiutil create/detach, but for "convert". Added same workaround to repeat command. I also added repeat for "udifrez" command just in case. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1687 From herrick at openjdk.java.net Wed Dec 9 18:27:41 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 9 Dec 2020 18:27:41 GMT Subject: RFR: 8257924: Use full path when running external executable from jpackage In-Reply-To: References: Message-ID: <8EWBsu3k99NaOttB704LB7TzCoPvQx-DriOdMxmBebY=.deb045a4-b4ae-4249-8e7f-2bb4aeceda9b@github.com> On Wed, 9 Dec 2020 08:05:17 GMT, Alexander Matveev wrote: > Changed all external executables to run via full path to avoid potential issues. as long as your sure these are always in /usr/bin this is fine. If there is any chance of them being somewhere else instead we need a findTool type mechanism ------------- PR: https://git.openjdk.java.net/jdk/pull/1710 From asemenyuk at openjdk.java.net Wed Dec 9 18:38:40 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 9 Dec 2020 18:38:40 GMT Subject: RFR: 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways In-Reply-To: References: Message-ID: <-jQlsFbifq_OlSLnCsnxfcx2cOdbVYDD6tAB1b_QaHY=.e2819b25-591e-4f5f-85cf-a7c36c43b585@github.com> On Tue, 8 Dec 2020 07:45:30 GMT, Alexander Matveev wrote: > This is similar issue we used to have for hdiutil create/detach, but for "convert". Added same workaround to repeat command. I also added repeat for "udifrez" command just in case. Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1687 From asemenyuk at openjdk.java.net Wed Dec 9 18:41:38 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 9 Dec 2020 18:41:38 GMT Subject: RFR: 8257924: Use full path when running external executable from jpackage In-Reply-To: <8EWBsu3k99NaOttB704LB7TzCoPvQx-DriOdMxmBebY=.deb045a4-b4ae-4249-8e7f-2bb4aeceda9b@github.com> References: <8EWBsu3k99NaOttB704LB7TzCoPvQx-DriOdMxmBebY=.deb045a4-b4ae-4249-8e7f-2bb4aeceda9b@github.com> Message-ID: <4D5Io4wOEKaRRC1jCSk6rJ-pKFe-kLG69WwAk-j4FcE=.b76d822a-71f4-4c49-b169-6c32c98f7d17@github.com> On Wed, 9 Dec 2020 18:06:42 GMT, Andy Herrick wrote: >> Changed all external executables to run via full path to avoid potential issues. > > as long as your sure these are always in /usr/bin this is fine. > If there is any chance of them being somewhere else instead we need a findTool type mechanism What if users would like to use not the default tools with jpackage? ------------- PR: https://git.openjdk.java.net/jdk/pull/1710 From prappo at openjdk.java.net Wed Dec 9 18:43:36 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 9 Dec 2020 18:43:36 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 21:15:48 GMT, Martin Buchholz wrote: >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > JDK-8234131 The changes to doc comments look good. Thanks for incorporating my earlier code snippet suggestions published on [concurrency-interest](http://cs.oswego.edu/pipermail/concurrency-interest/2020-November/017264.html)! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 2102: > 2100: * dropped.cancel(false); // also consider logging the failure > 2101: * e.execute(r); // retry > 2102: * }}} I tried to reify that code snippet: $ cat MySnippet.java import java.util.concurrent.Future; import java.util.concurrent.RejectedExecutionHandler; import java.util.concurrent.ThreadPoolExecutor; public class MySnippet { public static void main(String[] args) { new RejectedExecutionHandler() { public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { Future dropped = e.getQueue().poll(); if (dropped != null) dropped.cancel(false); // also consider logging the failure e.execute(r); // retry } }; } } $ javac MySnippet.java MySnippet.java:9: error: incompatible types: Runnable cannot be converted to Future Future dropped = e.getQueue().poll(); ^ 1 error $ Separately, it seems that the `if` statement uses a 3-space indent which is surprising to see in the JSR 166 code base. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1647 From mandy.chung at oracle.com Wed Dec 9 18:44:26 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Dec 2020 10:44:26 -0800 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com> Message-ID: <3f160ca4-1822-d4f6-148a-ddd30a7d737a@oracle.com> On 12/8/20 6:02 PM, Johannes Kuhn wrote: > There are a lot of things to consider when trying to fix JDK-8013527. Exactly in particular security implication!? What is clear is that the expected lookup class should not be the injected class.?? The key message here is that we can't fix JDK-8257874 until we fix JDK-8013527 unfortunately. Mandy From almatvee at openjdk.java.net Wed Dec 9 18:54:35 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Dec 2020 18:54:35 GMT Subject: RFR: 8257924: Use full path when running external executable from jpackage In-Reply-To: <4D5Io4wOEKaRRC1jCSk6rJ-pKFe-kLG69WwAk-j4FcE=.b76d822a-71f4-4c49-b169-6c32c98f7d17@github.com> References: <8EWBsu3k99NaOttB704LB7TzCoPvQx-DriOdMxmBebY=.deb045a4-b4ae-4249-8e7f-2bb4aeceda9b@github.com> <4D5Io4wOEKaRRC1jCSk6rJ-pKFe-kLG69WwAk-j4FcE=.b76d822a-71f4-4c49-b169-6c32c98f7d17@github.com> Message-ID: On Wed, 9 Dec 2020 18:39:14 GMT, Alexey Semenyuk wrote: >> as long as your sure these are always in /usr/bin this is fine. >> If there is any chance of them being somewhere else instead we need a findTool type mechanism > > What if users would like to use not the default tools with jpackage? I did not found any information if it is possible for these tools to locate somewhere else. These tools a part of macOS, so I do not think that it is possible to use some non-default tools and I am not aware that such substitute tools even exist. ------------- PR: https://git.openjdk.java.net/jdk/pull/1710 From mcimadamore at openjdk.java.net Wed Dec 9 19:01:36 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 9 Dec 2020 19:01:36 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 23:55:05 GMT, Claes Redestad wrote: >> See here: >> https://github.com/mcimadamore/jdk/runs/1460615378 >> >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/foreign/TestSegments.java >> >> STDERR: >> Invalid maximum heap size: -Xmx4G >> The specified size exceeds the maximum representable size. >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> Adding `@requires` in the same form other `java/foreign` tests have it skips the test on 32-bit platforms. >> >> Additional testing: >> - [x] Affected test on Linux x86_32 (skipped now) >> - [x] Affected test on Linux x86_64 (still passes) > > Marked as reviewed by redestad (Reviewer). Lowering the mx size to 3G works - and I believe should work on 32bits too? Disabling the entire test seems a bit overkill IMHO. ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From herrick at openjdk.java.net Wed Dec 9 19:03:40 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 9 Dec 2020 19:03:40 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 Message-ID: Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed up with merge ------------- Commit messages: - JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 Changes: https://git.openjdk.java.net/jdk/pull/1720/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1720&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257539 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1720/head:pull/1720 PR: https://git.openjdk.java.net/jdk/pull/1720 From almatvee at openjdk.java.net Wed Dec 9 19:05:36 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Dec 2020 19:05:36 GMT Subject: Integrated: 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 07:45:30 GMT, Alexander Matveev wrote: > This is similar issue we used to have for hdiutil create/detach, but for "convert". Added same workaround to repeat command. I also added repeat for "udifrez" command just in case. This pull request has now been integrated. Changeset: e6b4c4d7 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/e6b4c4d7 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways Reviewed-by: herrick, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/1687 From hseigel at openjdk.java.net Wed Dec 9 19:11:35 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 9 Dec 2020 19:11:35 GMT Subject: Integrated: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavior conforms to the JVM Spec. > > This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes. > > This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: d33a689b Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/d33a689b Stats: 167 lines in 8 files changed: 106 ins; 13 del; 48 mod 8256867: Classes with empty PermittedSubclasses attribute cannot be extended Reviewed-by: lfoltan, mchung, jlahoda, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1675 From github.com+741251+turbanoff at openjdk.java.net Wed Dec 9 19:23:33 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 9 Dec 2020 19:23:33 GMT Subject: Integrated: 6882207: Convert javap to use diamond operator internally In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:30:07 GMT, Andrey Turbanov wrote: > 6882207: Convert javap to use diamond operator internally This pull request has now been integrated. Changeset: 30de320c Author: Andrey Turbanov Committer: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/30de320c Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 6882207: Convert javap to use diamond operator internally Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/1677 From almatvee at openjdk.java.net Wed Dec 9 19:29:33 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Dec 2020 19:29:33 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: <2HMa6qsacyHfVoTcZ5_tfsp-buipPjyMOnhXhV0tdYk=.17e416d0-72a9-4fa5-9f54-4e41c91484bf@github.com> On Wed, 9 Dec 2020 18:58:54 GMT, Andy Herrick wrote: > Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed up with merge Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1720 From info at j-kuhn.de Wed Dec 9 20:09:32 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Wed, 9 Dec 2020 21:09:32 +0100 Subject: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive In-Reply-To: <3f160ca4-1822-d4f6-148a-ddd30a7d737a@oracle.com> References: <5d39710a-ab78-4953-3f9f-86fd1b34b5d9@j-kuhn.de> <8b92389c-1c02-785e-7d33-6ae8a30d2a1c@oracle.com> <54ee3c75-3533-15eb-cba0-c13e6e2cc73b@oracle.com> <1b21c701-d266-c99d-80cd-ec7a423a1cd2@oracle.com> <3f160ca4-1822-d4f6-148a-ddd30a7d737a@oracle.com> Message-ID: On 09-Dec-20 19:44, Mandy Chung wrote: > > > On 12/8/20 6:02 PM, Johannes Kuhn wrote: >> There are a lot of things to consider when trying to fix JDK-8013527. > > Exactly in particular security implication!? What is clear is that the > expected lookup class should not be the injected class.?? The key > message here is that we can't fix JDK-8257874 until we fix JDK-8013527 > unfortunately. > > Mandy > Yeah, if JDK-8013527 is fixed it might fix JDK-8257874 as a byproduct. If Lookup.lookup() can determine the original caller, then Field.set*/Method.invoke could do the same. Special care has to be taken that no other class could spoof such an injected invoker. Too complicated for me :). JDK-8013527 needs a sound design to approach fixing it IMHO. - Johannes From martin at openjdk.java.net Wed Dec 9 20:20:49 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Wed, 9 Dec 2020 20:20:49 GMT Subject: RFR: 8246585: ForkJoin updates [v3] In-Reply-To: References: Message-ID: > 8246585: ForkJoin updates Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: JDK-8246585 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1646&range=02 Stats: 3291 lines in 7 files changed: 1312 ins; 890 del; 1089 mod Patch: https://git.openjdk.java.net/jdk/pull/1646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1646/head:pull/1646 PR: https://git.openjdk.java.net/jdk/pull/1646 From joehw at openjdk.java.net Wed Dec 9 21:42:37 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 9 Dec 2020 21:42:37 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v4] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 11:49:51 GMT, Michael Edgar wrote: >> Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. >> >> Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). > > Michael Edgar has updated the pull request incrementally with one additional commit since the last revision: > > Additional test class clean-up Looks good! Some minor comments below. test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/XMLStreamReaderFilterTest.java line 60: > 58: * {@code XMLStreamException} thrown when the underlying XML is not valid and > 59: * the filter condition requires that the original reader is advanced past the > 60: * invalid data. This test verifies an assertion made by the javadoc for the createFilteredReader method. It would be good to made the first sentence a summary of the test. Something like: Verifies that XMLStreamException is thrown as specified by the {@code XMLInputFactory::createFilteredReader} method when an error is encountered. This test illustrates the scenario by creating a reader with a filter that requires the original reader to advance past the invalid element in the underlying XML. test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/XMLStreamReaderFilterTest.java line 64: > 62: */ > 63: @Test > 64: public void testXMLStreamReaderExceptionThrownByConstructor() throws Exception { Method name is a bit long. Since the class is dedicated to testing StreamFilter, its test cases may just indicate their particular cases. I would think testCreateFilteredReader is sufficient. test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/XMLStreamReaderFilterTest.java line 65: > 63: @Test > 64: public void testXMLStreamReaderExceptionThrownByConstructor() throws Exception { > 65: StreamFilter filter = r -> r.getEventType() == XMLStreamConstants.START_ELEMENT && r.getLocalName().equals("element3"); Keeping the length to under 100 characters is still a good practice even with wide screens, 80 - 100 would be good as it's easier to read with a side-by-side view. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1209 From martinrb at google.com Wed Dec 9 22:11:00 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Dec 2020 14:11:00 -0800 Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3] In-Reply-To: References: Message-ID: Thanks, Pavel! I committed this to CVS, but am not planning to include it in this integration: (not sure if re-generating will invalidate my "Ready" status) (Having to cast to Future makes this more problematic, but in typical usages the user will know that the queue contains Futures) --- src/main/java/util/concurrent/ThreadPoolExecutor.java 8 Dec 2020 20:33:21 -0000 1.195 +++ src/main/java/util/concurrent/ThreadPoolExecutor.java 9 Dec 2020 22:05:21 -0000 1.197 @@ -2066,10 +2066,12 @@ * 
 {@code
      * new RejectedExecutionHandler() {
      *   public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
-     *     Future dropped = e.getQueue().poll();
-     *     if (dropped != null)
-     *        dropped.cancel(false); // also consider logging the failure
-     *     e.execute(r);             // retry
+     *     Runnable dropped = e.getQueue().poll();
+     *     if (dropped instanceof Future) {
+     *       ((Future)dropped).cancel(false);
+     *       // also consider logging the failure
+     *     }
+     *     e.execute(r);  // retry
      * }}}
*/ public static class DiscardOldestPolicy implements RejectedExecutionHandler { On Wed, Dec 9, 2020 at 10:46 AM Pavel Rappo wrote: > On Tue, 8 Dec 2020 21:15:48 GMT, Martin Buchholz > wrote: > > >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > > > Martin Buchholz has updated the pull request with a new target base due > to a merge or a rebase. The pull request now contains one commit: > > > > JDK-8234131 > > The changes to doc comments look good. > > Thanks for incorporating my earlier code snippet suggestions published on > [concurrency-interest]( > http://cs.oswego.edu/pipermail/concurrency-interest/2020-November/017264.html > )! > > src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java > line 2102: > > > 2100: * dropped.cancel(false); // also consider logging the > failure > > 2101: * e.execute(r); // retry > > 2102: * }}} > > I tried to reify that code snippet: > > $ cat MySnippet.java > import java.util.concurrent.Future; > import java.util.concurrent.RejectedExecutionHandler; > import java.util.concurrent.ThreadPoolExecutor; > > public class MySnippet { > public static void main(String[] args) { > new RejectedExecutionHandler() { > public void rejectedExecution(Runnable r, ThreadPoolExecutor > e) { > Future dropped = e.getQueue().poll(); > if (dropped != null) > dropped.cancel(false); // also consider logging the > failure > e.execute(r); // retry > } > }; > } > } > $ javac MySnippet.java > MySnippet.java:9: error: incompatible types: Runnable cannot be converted > to Future > Future dropped = e.getQueue().poll(); > ^ > 1 error > $ > Separately, it seems that the `if` statement uses a 3-space indent which > is surprising to see in the JSR 166 code base. > > ------------- > > Marked as reviewed by prappo (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1647 > From jiefu at openjdk.java.net Wed Dec 9 23:16:34 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 9 Dec 2020 23:16:34 GMT Subject: RFR: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186 In-Reply-To: References: Message-ID: <8aMVBRW6BN_mCnfUGjymV92gsZk4Sd9anC6N7g_k4Jk=.683bd630-1f1f-448a-bb62-a5c7edc67252@github.com> On Wed, 9 Dec 2020 18:57:52 GMT, Maurizio Cimadamore wrote: > Lowering the mx size to 3G works - and I believe should work on 32bits too? Disabling the entire test seems a bit overkill IMHO. I think -Xmx3G may be still easily broken on some 32-bit platforms since 3G >> 3800 / 2 =1900M. ------------- PR: https://git.openjdk.java.net/jdk/pull/1688 From asemenyuk at openjdk.java.net Thu Dec 10 00:09:33 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 10 Dec 2020 00:09:33 GMT Subject: RFR: 8257924: Use full path when running external executable from jpackage In-Reply-To: References: Message-ID: <9xZUFrhNOK96yrxTsMcAd8eG56wLsB2wdE_-rejwZlQ=.e3bcf251-0279-4ded-90ba-96b79d15d2ea@github.com> On Wed, 9 Dec 2020 08:05:17 GMT, Alexander Matveev wrote: > Changed all external executables to run via full path to avoid potential issues. Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1710 From prappo at openjdk.java.net Thu Dec 10 00:10:36 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 10 Dec 2020 00:10:36 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: References: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com> Message-ID: On Wed, 25 Nov 2020 20:22:21 GMT, Daniel Fuchs wrote: >> @pavelrappo >> >>> What is the required level of fidelity particular (pseudo-) code has to have? >> >> It's potentially a large discussion, one that could be had in the context of my JEP draft http://openjdk.java.net/jeps/8068562 . However, speaking practically, it's possible to focus the discussion fairly concisely: the main responsibility of the `@implSpec` ("Implementation Requirements") section is to give implementors of subclasses enough information to decide whether to inherit the implementation or to override it, and if they override it, what behavior they can expect if they were to call `super.compute`. >> >> In this case, a null-value-tolerating Map implementation needs to know that the default implementation calls `remove` in the particular case that you mentioned. A concurrent Map implementation will also need to know that the default implementation calls `get(key)` and `containsKey(key)` at different times, potentially leading to a race condition. Both of these inform the override vs. inherit decision. > > @stuart-marks > >> Both of these inform the override vs. inherit decision. > > So in this case - fixing the specification to match the default implementation seems to be the right call - as existing implementations that do not override are more probably depending on the current default behavior. @dfuch, @stuart-marks, and @Martin-Buchholz: thanks for reviewing the CSR. @johnlinp: I have finalized the CSR; now we are waiting for it to be approved. ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From asemenyuk at openjdk.java.net Thu Dec 10 00:10:36 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 10 Dec 2020 00:10:36 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 18:58:54 GMT, Andy Herrick wrote: > Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed up with merge Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1720 From prr at openjdk.java.net Thu Dec 10 00:27:37 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 10 Dec 2020 00:27:37 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 18:58:54 GMT, Andy Herrick wrote: > Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed up with merge Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1720 From kizune at openjdk.java.net Thu Dec 10 00:34:35 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 10 Dec 2020 00:34:35 GMT Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 18:58:54 GMT, Andy Herrick wrote: > Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed up with merge Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1720 From weijun at openjdk.java.net Thu Dec 10 00:46:35 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 10 Dec 2020 00:46:35 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> 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. >> >> ### Modules reviewed >> >> - [ ] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [ ] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Move to share/data, and move jdwp.spec to java.se The security-related part (cacerts, blacklisted.certs, publicsuffxlist) looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From herrick at openjdk.java.net Thu Dec 10 00:53:35 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 10 Dec 2020 00:53:35 GMT Subject: Integrated: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 18:58:54 GMT, Andy Herrick wrote: > Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed up with merge This pull request has now been integrated. Changeset: 1ce2a36c Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/1ce2a36c Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 Reviewed-by: almatvee, asemenyuk, prr, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/1720 From herrick at openjdk.java.net Thu Dec 10 00:56:33 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 10 Dec 2020 00:56:33 GMT Subject: RFR: 8257924: Use full path when running external executable from jpackage In-Reply-To: References: Message-ID: <6ZczYQGRHOWG9TcMnIUi4_kGmbiooewM3wSWqAeGIIY=.4fff78e1-03cb-423d-9a50-89437f8e790a@github.com> On Wed, 9 Dec 2020 08:05:17 GMT, Alexander Matveev wrote: > Changed all external executables to run via full path to avoid potential issues. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1710 From almatvee at openjdk.java.net Thu Dec 10 01:04:35 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 10 Dec 2020 01:04:35 GMT Subject: Integrated: 8257924: Use full path when running external executable from jpackage In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 08:05:17 GMT, Alexander Matveev wrote: > Changed all external executables to run via full path to avoid potential issues. This pull request has now been integrated. Changeset: eb1c8a15 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/eb1c8a15 Stats: 22 lines in 9 files changed: 1 ins; 0 del; 21 mod 8257924: Use full path when running external executable from jpackage Reviewed-by: herrick, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/1710 From github.com+20868526+mikeedgar at openjdk.java.net Thu Dec 10 01:08:35 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Thu, 10 Dec 2020 01:08:35 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v4] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 21:39:26 GMT, Joe Wang wrote: >> Michael Edgar has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional test class clean-up > > Looks good! Some minor comments below. @JoeWang-Java - thanks for the additional feedback - all good. Do you suggest I make them now in this PR? Just confirming before pushing the change and dismissing your approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From smarks at openjdk.java.net Thu Dec 10 01:35:35 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Dec 2020 01:35:35 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == In-Reply-To: References: <87yS9DH4_CxvLZYSVYcw5bham03wLB0sVHQWY0nGMBk=.b6af4284-f3c7-4a1e-920b-915663fe38e6@github.com> Message-ID: On Tue, 8 Dec 2020 22:12:29 GMT, Joe Darcy wrote: >> I'll note initially that the original bug is about `equals` and `==` whereas this change also covers `compareTo` and additional comparison operators `<` and `>`. I believe covering this additional material **IS** important, as these concepts are all closely related. >> >> While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice. >> >> (One additional concept that ought to be covered is that `compareTo` is *consistent with equals*. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.) >> >> I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in `Double`. The various methods can then make some terse assertions and then refer to the combined explanation. `Float` could refer to `Double` instead of replicating the text. >> >> Another alternative is to put this explanation into the `java.lang` package specification. This might be a good fit, since there is already some explanation there of the boxed primitives. > >> >> >> I'll note initially that the original bug is about `equals` and `==` whereas this change also covers `compareTo` and additional comparison operators `<` and `>`. I believe covering this additional material **IS** important, as these concepts are all closely related. >> >> While this material is covering the right ground, I'd say that it's too verbose for a method specification. It feels like it's being compressed to fit into a method specification and thus doesn't do the topic justice. >> >> (One additional concept that ought to be covered is that `compareTo` is _consistent with equals_. This should be asserted in the method specification, but trying to explain it in a method specification seems difficult.) >> >> I'll suggest a couple alternatives. One is to put a full, combined explanation into class doc somewhere, say in `Double`. The various methods can then make some terse assertions and then refer to the combined explanation. `Float` could refer to `Double` instead of replicating the text. >> >> Another alternative is to put this explanation into the `java.lang` package specification. This might be a good fit, since there is already some explanation there of the boxed primitives. > > > I added discussion of compareTo as well as equals to the scope of the bug since they are sibling surprising deviations from what is expected and have the same root cause. (I took care to say "incomplete order" rather than "partial order" since a partial order requires reflexivity.) > > The interface java.lang.Comparable gives a definition of "consistent with equals." I didn't verify it doesn't have an anchor to link to, but we don't typically link to the definition. However, I wouldn't be adverse to having "consistent with equals" link to Comparable; that would be more obvious than expecting the reader to follow the "Specified by: compareTo in interface Comparable" link javadoc generates for the method. > > I think the Float and Double equals and compareTo methods should at least get pointers to any new section added -- I think a standalone section in the package javadoc by itself would have low discoverability. > > I'm make another iteration over the text; thanks. Great, let me know if you'd like me to provide some text for any particular topics in this area. ------------- PR: https://git.openjdk.java.net/jdk/pull/1699 From joehw at openjdk.java.net Thu Dec 10 02:09:35 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 10 Dec 2020 02:09:35 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v4] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 01:06:16 GMT, Michael Edgar wrote: >> Looks good! Some minor comments below. > > @JoeWang-Java - thanks for the additional feedback - all good. Do you suggest I make them now in this PR? Just confirming before pushing the change and dismissing your approval. Yes, please make the changes. Approval will be quick :-) (since this is the last day for low priority changes) ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From github.com+20868526+mikeedgar at openjdk.java.net Thu Dec 10 02:42:51 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Thu, 10 Dec 2020 02:42:51 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v5] In-Reply-To: References: Message-ID: > Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. > > Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). Michael Edgar has updated the pull request incrementally with one additional commit since the last revision: Apply comment, naming, and formatting suggestions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1209/files - new: https://git.openjdk.java.net/jdk/pull/1209/files/a416b276..9a9c64dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=03-04 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1209/head:pull/1209 PR: https://git.openjdk.java.net/jdk/pull/1209 From github.com+20868526+mikeedgar at openjdk.java.net Thu Dec 10 02:42:51 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Thu, 10 Dec 2020 02:42:51 GMT Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException [v4] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 02:07:14 GMT, Joe Wang wrote: >> @JoeWang-Java - thanks for the additional feedback - all good. Do you suggest I make them now in this PR? Just confirming before pushing the change and dismissing your approval. > > Yes, please make the changes. Approval will be quick :-) (since this is the last day for low priority changes) Done - please let me know if anything else is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From github.com+20868526+mikeedgar at openjdk.java.net Thu Dec 10 03:42:36 2020 From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar) Date: Thu, 10 Dec 2020 03:42:36 GMT Subject: Integrated: 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException In-Reply-To: References: Message-ID: <2jjrlm-OYNgnuxe9jPzmaMWhFVpyMuoEI0p1sFgFzNs=.76d5fd85-2c6e-4b3b-869a-b6b1fa06b35a@github.com> On Fri, 13 Nov 2020 22:14:47 GMT, Michael Edgar wrote: > Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`. > > Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`). This pull request has now been integrated. Changeset: 6847bbbb Author: Michael Edgar Committer: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/6847bbbb Stats: 103 lines in 2 files changed: 91 ins; 7 del; 5 mod 8255918: XMLStreamFilterImpl constructor consumes XMLStreamException Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/1209 From darcy at openjdk.java.net Thu Dec 10 04:42:55 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Dec 2020 04:42:55 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v7] In-Reply-To: References: Message-ID: > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Get in JEP 390 changes. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update symbol files for JDK 16b27. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/bbfda542...766c2c01 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/57ba7b64..766c2c01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=05-06 Stats: 4920 lines in 147 files changed: 3195 ins; 1060 del; 665 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From darcy at openjdk.java.net Thu Dec 10 08:24:56 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Dec 2020 08:24:56 GMT Subject: RFR: 8257450: Start of release updates for JDK 17 [v8] In-Reply-To: References: Message-ID: > Start of JDK 17 updates. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Get in JEP 390 changes. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - Update symbol files for JDK 16b27. - Merge branch 'master' into JDK-8257450 - Merge branch 'master' into JDK-8257450 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/61f30b72...553d134f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1531/files - new: https://git.openjdk.java.net/jdk/pull/1531/files/766c2c01..553d134f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=06-07 Stats: 554 lines in 7 files changed: 324 ins; 220 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531 PR: https://git.openjdk.java.net/jdk/pull/1531 From kbarrett at openjdk.java.net Thu Dec 10 08:37:35 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 08:37:35 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 13:28:44 GMT, Thomas Schatzl wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java >> jdk/java/lang/ref/ReferenceEnqueue.java >> >> In each of them, some combination of using Reference.refersTo and >> ReferenceQueue.remove with a timeout were used to eliminate the use of >> Reference.isEnqueued. >> >> I also cleaned up ReferencesGC.java in various respects. It contained >> several bits of dead code, and the failure checks were made stronger. >> >> Testing: >> mach5 tier1 >> Locally (linux-x64) ran all three tests with each GC (including Shenandoah). > > Changes requested by tschatzl (Reviewer). > [pre-existing] The topWeakReferenceGC.java description at the top describes that the test calls System.gc() explicitly to trigger garbage collections at the end. It does not. Maybe this could be weasel-worded around like in the other cases in that text. There are a lot of things much more wrong with that comment. Doing more GCs doesn't cause more enqueues to happen. The "non-deterministic" enqueuing is just a race. The GC adds references to the pending list. The reference processing thread transfers references from the pending list to their associated queue (if any). The test code is racing with that. The change to use Reference.remove with a timeout eliminates all that, and one GC should be. Addressing all that would be a substantial rewrite of this test though. Mind if I defer that to a new RFE? ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From kbarrett at openjdk.java.net Thu Dec 10 08:46:36 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 08:46:36 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 13:26:04 GMT, Thomas Schatzl wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java >> jdk/java/lang/ref/ReferenceEnqueue.java >> >> In each of them, some combination of using Reference.refersTo and >> ReferenceQueue.remove with a timeout were used to eliminate the use of >> Reference.isEnqueued. >> >> I also cleaned up ReferencesGC.java in various respects. It contained >> several bits of dead code, and the failure checks were made stronger. >> >> Testing: >> mach5 tier1 >> Locally (linux-x64) ran all three tests with each GC (including Shenandoah). > > test/hotspot/jtreg/vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java line 129: > >> 127: } >> 128: >> 129: int REMOVE = (int) (RANGE * RATIO); > > These two constants could be factored out as static finals to match the casing. I'm making REMOVE and RETAIN statics, near RANGE and RATIO. (Meant to do that before, but forgot.) They can't be final though, because RANGE and RATIO aren't final, and can be set from command line arguments. So they'll get initialized in parseArgs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From kbarrett at openjdk.java.net Thu Dec 10 09:01:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 09:01:54 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests [v2] In-Reply-To: References: Message-ID: <4JvCs53pm1rUddMiklt8Q5QgJXrloJDNblRbBDYDW6U=.5041142a-b99e-4e91-9871-5f996ca761a1@github.com> On Wed, 9 Dec 2020 13:59:09 GMT, Thomas Schatzl wrote: >> test/jdk/java/lang/ref/ReferenceEnqueue.java line 58: >> >>> 56: for (int i = 0; i < iterations; i++) { >>> 57: System.gc(); >>> 58: enqueued = (queue.remove(100) == ref); >> >> The code does not catch `InterruptedException` like it does in the other files. > > I understand that the test code previously just forwarded the `InterruptedException` if it happened in the `Thread.sleep()` call too. So this may only be an exiting issue and please ignore this comment. > Not catching `InterruptedException` here only seems to be a cause for unnecessary failure. Then again, it probably does not happen a lot. Nothing in the test calls Thread.interrupt(), so there isn't a risk of failure due to not handling that exception in some "interesting" way. But InterruptedException must be "handled" somehow, because it's a checked exception. That's already dealt with by the run() method declaring that it throws that type, and main declaring that it throws Exception. The other tests modified in this change don't take that approach (just let it propagate out through main), instead wrapping the interruptable calls in try/catch, though again just to satisfy the requirement that a checked exception must be statically verified to be handled, even though there aren't going to be any thrown. ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From kbarrett at openjdk.java.net Thu Dec 10 09:01:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 09:01:54 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests [v2] In-Reply-To: References: Message-ID: > Please review this change that eliminates the use of Reference.isEnqueued by > tests. There were three tests using it: > > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java > jdk/java/lang/ref/ReferenceEnqueue.java > > In each of them, some combination of using Reference.refersTo and > ReferenceQueue.remove with a timeout were used to eliminate the use of > Reference.isEnqueued. > > I also cleaned up ReferencesGC.java in various respects. It contained > several bits of dead code, and the failure checks were made stronger. > > Testing: > mach5 tier1 > Locally (linux-x64) ran all three tests with each GC (including Shenandoah). Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: move REMOVE and RETAIN decls and init ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1691/files - new: https://git.openjdk.java.net/jdk/pull/1691/files/e87206a8..01710567 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1691&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1691&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1691.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1691/head:pull/1691 PR: https://git.openjdk.java.net/jdk/pull/1691 From ngasson at openjdk.java.net Thu Dec 10 09:15:48 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 10 Dec 2020 09:15:48 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 08:20:38 GMT, Nick Gasson wrote: > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 @JornVernee and @mcimadamore could you take a look too? ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From ngasson at openjdk.java.net Thu Dec 10 09:15:47 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 10 Dec 2020 09:15:47 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1711/files - new: https://git.openjdk.java.net/jdk/pull/1711/files/a5f1b33b..99390b92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=00-01 Stats: 70 lines in 3 files changed: 12 ins; 45 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1711/head:pull/1711 PR: https://git.openjdk.java.net/jdk/pull/1711 From ngasson at openjdk.java.net Thu Dec 10 09:15:50 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 10 Dec 2020 09:15:50 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 09:58:26 GMT, Andrew Haley wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > src/hotspot/cpu/aarch64/aarch64.ad line 16057: > >> 16055: >> 16056: format %{ "CALL, native $meth" %} >> 16057: > > It might be better to expand this a little to indicate a near or a far call, if that's possible. That would be nice but I can't see how to do it: adlc doesn't allow arbitrary code inside `format %{ %}`. > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3186: > >> 3184: // Make sure that native code does not change SVE vector length. >> 3185: __ verify_sve_vector_length(); >> 3186: } > > Do we have to surround every call to verify_sve_vector_length() with if (UseSVE > 0) ? > Why is that check not inside verify_sve_vector_length() ? What is the meaning of the >> 0 comparison? Can it be negative? So many questions. :-) The valid values are {0,1,2} so > 0 is supposed to read as "SVE1 or SVE2". But I also think it's neater if the check is inside `verify_sve_vector_length` so I've moved it there. > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3098: > >> 3096: MacroAssembler* masm = _masm; >> 3097: if (reg->is_Register()) { >> 3098: __ push(RegSet::of(reg->as_Register()), sp); > > Is this right? SP is 16-aligned, so this will use 16 bytes of stack for every 8-byte register. Does it get used a lot? It's used to preserve the native result registers around the runtime calls in the safepoint and reguard slow paths. With the way the intrinsic works currently, there'll actually only ever be a single output register. I did it this way originally to keep the code similar to x86 but actually it's just as easy to build a `RegSet` directly and push that, so I've removed these functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From tschatzl at openjdk.java.net Thu Dec 10 09:27:33 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 10 Dec 2020 09:27:33 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 09:01:54 GMT, Kim Barrett wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java >> jdk/java/lang/ref/ReferenceEnqueue.java >> >> In each of them, some combination of using Reference.refersTo and >> ReferenceQueue.remove with a timeout were used to eliminate the use of >> Reference.isEnqueued. >> >> I also cleaned up ReferencesGC.java in various respects. It contained >> several bits of dead code, and the failure checks were made stronger. >> >> Testing: >> mach5 tier1 >> Locally (linux-x64) ran all three tests with each GC (including Shenandoah). > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > move REMOVE and RETAIN decls and init Also good with deferring the changes to the comments and the move of the statics. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1691 From tschatzl at openjdk.java.net Thu Dec 10 09:27:35 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 10 Dec 2020 09:27:35 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests [v2] In-Reply-To: <4JvCs53pm1rUddMiklt8Q5QgJXrloJDNblRbBDYDW6U=.5041142a-b99e-4e91-9871-5f996ca761a1@github.com> References: <4JvCs53pm1rUddMiklt8Q5QgJXrloJDNblRbBDYDW6U=.5041142a-b99e-4e91-9871-5f996ca761a1@github.com> Message-ID: On Thu, 10 Dec 2020 08:56:25 GMT, Kim Barrett wrote: >> I understand that the test code previously just forwarded the `InterruptedException` if it happened in the `Thread.sleep()` call too. So this may only be an exiting issue and please ignore this comment. >> Not catching `InterruptedException` here only seems to be a cause for unnecessary failure. Then again, it probably does not happen a lot. > > Nothing in the test calls Thread.interrupt(), so there isn't a risk of > failure due to not handling that exception in some "interesting" way. But > InterruptedException must be "handled" somehow, because it's a checked > exception. That's already dealt with by the run() method declaring that it > throws that type, and main declaring that it throws Exception. The other > tests modified in this change don't take that approach (just let it > propagate out through main), instead wrapping the interruptable calls in > try/catch, though again just to satisfy the requirement that a checked > exception must be statically verified to be handled, even though there > aren't going to be any thrown. Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From aph at openjdk.java.net Thu Dec 10 09:42:37 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 10 Dec 2020 09:42:37 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> On Thu, 10 Dec 2020 09:15:47 GMT, Nick Gasson wrote: >> This is more-or-less a straight port of the x86 code to AArch64. >> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() >> to generate a blob that jumps to the native function entry point. This >> simply switches the thread state from Java to native and handles the >> safepoint poll on return from native code. >> >> AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame >> pointer) may hold a live oop over the MachCallNative node. Normally this >> would be saved by RegisterSaver::save_live_registers() but the native >> invoker blob is not a "proper" stub routine so doesn't have an oop map. >> I copied the x86 solution to this where the frame pointer register is >> saved to the stack and a pointer to that is stored in the frame anchor. >> This is then read back and added to the register map when walking the >> stack. I saw in the PR comments [1] that this might be a temporary fix, >> but I'm not sure if there's any plan to change that now? >> >> Another potential fix might be to change the C2 register definition of >> R29 and R29_H to be save-on-call as below. This works for the >> TestStackWalk.java test case but I don't know whether it has other >> unintended side-effects. >> >> reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp >> reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); >> >> JMH results from jdk/incubator/foreign/CallOverhead.java to show it's >> working: >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op >> CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op >> CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op >> CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op >> CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op >> CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op >> CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op >> CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op >> CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op >> CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op >> CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op >> CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op >> CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op >> CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op >> CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op >> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op >> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op >> >> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3192: > 3190: spills += RegSet::of(output->as_Register()); > 3191: } else if (output->is_FloatRegister()) { > 3192: fp_spills += RegSet::of((Register)output->as_FloatRegister()); This looks very strange. Does it generate the correct code for FloatRegisters? ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From chegar at openjdk.java.net Thu Dec 10 09:48:35 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 10 Dec 2020 09:48:35 GMT Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4] In-Reply-To: <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com> References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com> <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com> Message-ID: On Mon, 30 Nov 2020 20:54:09 GMT, Brian Burkhalter wrote: >> Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add explicitly allocated heap carrier buffer tests >> - Replace Single with Loop > > Marked as reviewed by bpb (Reviewer). While the updated set of scenarios covered by this benchmark is reasonably (and vastly improves coverage), I find myself reluctant to add the last remaining buffer property - read-only views. It's time to template the generation of this code! ------------- PR: https://git.openjdk.java.net/jdk/pull/1430 From ngasson at openjdk.java.net Thu Dec 10 10:05:43 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 10 Dec 2020 10:05:43 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> References: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> Message-ID: On Thu, 10 Dec 2020 09:36:44 GMT, Andrew Haley wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3192: > >> 3190: spills += RegSet::of(output->as_Register()); >> 3191: } else if (output->is_FloatRegister()) { >> 3192: fp_spills += RegSet::of((Register)output->as_FloatRegister()); > > This looks very strange. Does it generate the correct code for FloatRegisters? Er... no. But not because of the cast. The `push(fp_spills)` below should be `push_fp(fp_spills)`. I'll add a FloatRegister constructor to RegSet so it doesn't need that any more. There's one other place that does it in cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From aph at openjdk.java.net Thu Dec 10 10:23:36 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 10 Dec 2020 10:23:36 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> Message-ID: On Thu, 10 Dec 2020 10:01:49 GMT, Nick Gasson wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3192: >> >>> 3190: spills += RegSet::of(output->as_Register()); >>> 3191: } else if (output->is_FloatRegister()) { >>> 3192: fp_spills += RegSet::of((Register)output->as_FloatRegister()); >> >> This looks very strange. Does it generate the correct code for FloatRegisters? > > Er... no. But not because of the cast. The `push(fp_spills)` below should be `push_fp(fp_spills)`. I'll add a FloatRegister constructor to RegSet so it doesn't need that any more. There's one other place that does it in cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp push_fp() doesn't make much sense if the RegSet is a set of Registers, which are by definition not FloatRegisters. That casting of Register to FloatRegister in gc/z is evil. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From ngasson at openjdk.java.net Thu Dec 10 10:28:35 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 10 Dec 2020 10:28:35 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> Message-ID: On Thu, 10 Dec 2020 10:21:09 GMT, Andrew Haley wrote: >> Er... no. But not because of the cast. The `push(fp_spills)` below should be `push_fp(fp_spills)`. I'll add a FloatRegister constructor to RegSet so it doesn't need that any more. There's one other place that does it in cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp > > push_fp() doesn't make much sense if the RegSet is a set of Registers, which are by definition not FloatRegisters. That casting of Register to FloatRegister in gc/z is evil. Should we have a separate RegSet type for FloatRegisters to avoid mixing them up? ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From kbarrett at openjdk.java.net Thu Dec 10 10:37:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 10:37:54 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests [v3] In-Reply-To: References: Message-ID: <-S0WCahnGx8E1KkBszTUFJP0xiAo6n9ffFGiSGeHPnw=.a46180c0-ff19-4cbf-aee9-117f7a9ea717@github.com> > Please review this change that eliminates the use of Reference.isEnqueued by > tests. There were three tests using it: > > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java > jdk/java/lang/ref/ReferenceEnqueue.java > > In each of them, some combination of using Reference.refersTo and > ReferenceQueue.remove with a timeout were used to eliminate the use of > Reference.isEnqueued. > > I also cleaned up ReferencesGC.java in various respects. It contained > several bits of dead code, and the failure checks were made stronger. > > Testing: > mach5 tier1 > Locally (linux-x64) ran all three tests with each GC (including Shenandoah). Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into no_isenqueued - move REMOVE and RETAIN decls and init - update WeakReferenceGC test - update ReferenceQueue test - update ReferencesGC test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1691/files - new: https://git.openjdk.java.net/jdk/pull/1691/files/01710567..d5355342 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1691&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1691&range=01-02 Stats: 7952 lines in 328 files changed: 5091 ins; 1646 del; 1215 mod Patch: https://git.openjdk.java.net/jdk/pull/1691.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1691/head:pull/1691 PR: https://git.openjdk.java.net/jdk/pull/1691 From kbarrett at openjdk.java.net Thu Dec 10 10:37:55 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 10:37:55 GMT Subject: Integrated: 8257876: Avoid Reference.isEnqueued in tests In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote: > Please review this change that eliminates the use of Reference.isEnqueued by > tests. There were three tests using it: > > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java > jdk/java/lang/ref/ReferenceEnqueue.java > > In each of them, some combination of using Reference.refersTo and > ReferenceQueue.remove with a timeout were used to eliminate the use of > Reference.isEnqueued. > > I also cleaned up ReferencesGC.java in various respects. It contained > several bits of dead code, and the failure checks were made stronger. > > Testing: > mach5 tier1 > Locally (linux-x64) ran all three tests with each GC (including Shenandoah). This pull request has now been integrated. Changeset: db5da961 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/db5da961 Stats: 104 lines in 3 files changed: 23 ins; 39 del; 42 mod 8257876: Avoid Reference.isEnqueued in tests Reviewed-by: mchung, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From aph at openjdk.java.net Thu Dec 10 10:50:36 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 10 Dec 2020 10:50:36 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> Message-ID: On Thu, 10 Dec 2020 10:25:33 GMT, Nick Gasson wrote: >> push_fp() doesn't make much sense if the RegSet is a set of Registers, which are by definition not FloatRegisters. That casting of Register to FloatRegister in gc/z is evil. > > Should we have a separate RegSet type for FloatRegisters to avoid mixing them up? Absolutely. I'd make an AbstractRegSet and use it as a base type for both RegSet and FloatRegSet, then we can get rid of the casts altogether. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From kbarrett at openjdk.java.net Thu Dec 10 12:09:40 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 12:09:40 GMT Subject: RFR: 8257876: Avoid Reference.isEnqueued in tests [v3] In-Reply-To: <2TbNnDlF1nuEFWLddNG3wdj5EL0gg-1hzGwe2-emoQE=.e950f0f7-6be0-426d-8634-bc3c3175030a@github.com> References: <2TbNnDlF1nuEFWLddNG3wdj5EL0gg-1hzGwe2-emoQE=.e950f0f7-6be0-426d-8634-bc3c3175030a@github.com> Message-ID: On Tue, 8 Dec 2020 17:30:11 GMT, Mandy Chung wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into no_isenqueued >> - move REMOVE and RETAIN decls and init >> - update WeakReferenceGC test >> - update ReferenceQueue test >> - update ReferencesGC test > > Marked as reviewed by mchung (Reviewer). Thanks for reviews @mlchung and @tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1691 From thomas.vatter at network-inventory.de Thu Dec 10 12:12:45 2020 From: thomas.vatter at network-inventory.de (Thomas Vatter) Date: Thu, 10 Dec 2020 13:12:45 +0100 Subject: JNLP Message-ID: <95564547-8f9f-73ee-278a-7e6c728d9b2b@network-inventory.de> I'm using JNLP, how should I go on? -- Network Inventory Software IBM-Partner, RedHat- und SUSE-Partner, Oracle Technet Member www.network-inventory.de Tel. 030-79782510 Fax 030-79782512 E-Mail: thomas.vatter at network-inventory.de From mcimadamore at openjdk.java.net Thu Dec 10 13:20:47 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Dec 2020 13:20:47 GMT Subject: RFR: 8257837: Performance regression in heap byte buffer views Message-ID: As a result of the recent integration of the foreign memory access API, some of the buffer implementations now use `ScopedMemoryAccess` instead of `Unsafe`. While this works generally well, there are situations where profile pollution arises, which result in a considerable slowdown. The profile pollution occurs because the same ScopedMemoryAccess method (e.g. `getIntUnaligned`) is called with two different buffer kinds (e.g. an off heap buffer where base == null, and an on-heap buffer where base == byte[]). Because of that, unsafe access cannot be optimized, since C2 can't guess what the unsafe base access is. In reality, this problem was already known (and solved) elsewhere: the sun.misc.Unsafe wrapper does basically the same thing that ScopedMemoryAccess does. To make sure that profile pollution does not occur in those cases, argument profiling is enabled for sun.misc.Unsafe as well. This patch adds yet another case for ScopedMemoryAccess. Here are the benchmark results: Before: Benchmark Mode Cnt Score Error Units LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.612 ? 0.005 ms/op LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 2.740 ? 0.039 ms/op LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.504 ? 0.020 ms/op After Benchmark Mode Cnt Score Error Units LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.613 ? 0.007 ms/op LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 0.304 ? 0.002 ms/op LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.491 ? 0.004 ms/op ------------- Commit messages: - Add argument profiling for ScopedMemoryAccess Changes: https://git.openjdk.java.net/jdk/pull/1733/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1733&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257837 Stats: 121 lines in 3 files changed: 120 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1733/head:pull/1733 PR: https://git.openjdk.java.net/jdk/pull/1733 From hseigel at openjdk.java.net Thu Dec 10 13:44:35 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 13:44:35 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Hi Mandy, Could you regression test this change against the JCK lang and vm test suites and Mach5 tiers 1 and 2? Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From jvernee at openjdk.java.net Thu Dec 10 13:58:36 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Dec 2020 13:58:36 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 09:15:47 GMT, Nick Gasson wrote: >> This is more-or-less a straight port of the x86 code to AArch64. >> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() >> to generate a blob that jumps to the native function entry point. This >> simply switches the thread state from Java to native and handles the >> safepoint poll on return from native code. >> >> AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame >> pointer) may hold a live oop over the MachCallNative node. Normally this >> would be saved by RegisterSaver::save_live_registers() but the native >> invoker blob is not a "proper" stub routine so doesn't have an oop map. >> I copied the x86 solution to this where the frame pointer register is >> saved to the stack and a pointer to that is stored in the frame anchor. >> This is then read back and added to the register map when walking the >> stack. I saw in the PR comments [1] that this might be a temporary fix, >> but I'm not sure if there's any plan to change that now? >> >> Another potential fix might be to change the C2 register definition of >> R29 and R29_H to be save-on-call as below. This works for the >> TestStackWalk.java test case but I don't know whether it has other >> unintended side-effects. >> >> reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp >> reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); >> >> JMH results from jdk/incubator/foreign/CallOverhead.java to show it's >> working: >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op >> CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op >> CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op >> CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op >> CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op >> CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op >> CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op >> CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op >> CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op >> CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op >> CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op >> CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op >> CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op >> CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op >> CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op >> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op >> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op >> >> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Thanks for the amazing work! FWIW, on x86 RBP was being passed as debug info, so the solution Vlad I proposed would be to override MachCallNativeNode::in_RegMask to not include it IIRC. I haven't had time to look into it yet though. The situation on AArch64 seems to be different though? The RFP is not passed as debug info but as part of the normal calling convention maybe? src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3104: > 3102: const GrowableArray& output_registers) { > 3103: BufferBlob* _invoke_native_blob = > 3104: BufferBlob::create("nep_invoker_blob", MethodHandles::adapter_code_size); That reminds me; this should _not_ use MethodHandles::adapter_code_size, but a separate constant, since the former is tailored specifically to method handle stubs (and is too large for this case). I still need to update the one for x86 as well (looks like I forgot to do that one before when I changed them for invoker/upcall handler). I think 1024 bytes should be more than enough, but would need to test it. ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/jdk/pull/1711 From hseigel at openjdk.java.net Thu Dec 10 14:03:32 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 14:03:32 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Hi Mandy, Could you replace the comment starting at line 1854 in jvm.cpp with: // A class is a record if and only if it is final and a direct subclass // of java.lang.Record and the presence of `Record` attribute; // otherwise, it is not a record. Also, replace the comment starting at line 1872 in jvm.cpp with: // Returns an array containing the components of the Record attribute, // or NULL if the attribute is not present. // // Note that this function returns the components of the Record // attribute even if the class is not a Record. Also, please change the name of the attribute in the comments added to Class.java from RecordComponent to Record. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From jvernee at openjdk.java.net Thu Dec 10 14:04:35 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Dec 2020 14:04:35 GMT Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4] In-Reply-To: References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com> <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com> Message-ID: <5aRQdVf_tbxSwfbsvWMcqO_kBNTZ2m5RuZ6djoqGWQk=.a7c618fe-096f-43f9-b897-ba9ad4fd3dce@github.com> On Thu, 10 Dec 2020 09:46:07 GMT, Chris Hegarty wrote: >> Marked as reviewed by bpb (Reviewer). > > While the updated set of scenarios covered by this benchmark is > reasonably (and vastly improves coverage), I find myself reluctant to > add the last remaining buffer property - read-only views. It's time to > template the generation of this code! If the cases get to be too many, you might also want to consider splitting the benchmark class into several classes that cover different cases (we did this for the memory access benchmarks as well). That would also make it easier to run a subset of cases in isolation. ------------- PR: https://git.openjdk.java.net/jdk/pull/1430 From chegar at openjdk.java.net Thu Dec 10 14:16:34 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 10 Dec 2020 14:16:34 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From ecki at zusammenkunft.net Thu Dec 10 14:23:33 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 10 Dec 2020 14:23:33 +0000 Subject: JNLP In-Reply-To: <95564547-8f9f-73ee-278a-7e6c728d9b2b@network-inventory.de> References: <95564547-8f9f-73ee-278a-7e6c728d9b2b@network-inventory.de> Message-ID: Hello, We ported a big JWS gui app to stand-alone swing with a home made installer/update mechanism. This was very easy to do (it had a main method for debugging anyway). The installer is not the most comfortable, but we can live with it since the whole application will be replaced by an web app anyway. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Thomas Vatter Gesendet: Thursday, December 10, 2020 1:12:45 PM An: core-libs-dev at openjdk.java.net Betreff: JNLP I'm using JNLP, how should I go on? -- Network Inventory Software IBM-Partner, RedHat- und SUSE-Partner, Oracle Technet Member www.network-inventory.de Tel. 030-79782510 Fax 030-79782512 E-Mail: thomas.vatter at network-inventory.de From forax at univ-mlv.fr Thu Dec 10 14:26:12 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 Dec 2020 15:26:12 +0100 (CET) Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: <1230567086.503526.1607610372813.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mandy Chung" > ?: "core-libs-dev" , "hotspot-runtime-dev" > Envoy?: Mercredi 9 D?cembre 2020 01:43:34 > Objet: Re: RFR: 8257596: Clarify trusted final fields for record classes > On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on >> classes with Record attributes. That introduces a regression in >> `InstanceKlass::is_record` that returns true on a non-record class which has >> `RecordComponents` attribute present. This causes unexpected semantics in >> `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust >> final fields for non-record classes. >> >> I propose to change `InstanceKlass::is_record` to match the JLS semantic of a >> record class, i.e. final direct subclass of `java.lang.Record` with the >> presence of `RecordComponents` attribute. There is no change to JVM class file >> validation. Also I propose clearly define: >> - `JVM_IsRecord` returns true if the given class is a record i.e. final and >> direct subclass of `java.lang.Record` with `RecordComponents` attribute >> - `JVM_GetRecordComponents` returns an `RecordComponents` array if >> `RecordComponents` attribute is present; otherwise, returns NULL. This does >> not check if it's a record class or not. So it may return non-null on a >> non-record class if it has `RecordComponents` attribute. So >> `JVM_GetRecordComponents` returns the content of the classfile. > > Hi Remi, > >> It's not an issue, the JVM view of what a record is and the JLS view of what a >> record is doesn't have to be identical, >> only aligned. It's fine for the VM to consider any class that have a record >> Attribute is a record. >> >> We already had this discussion on amber-spec-expert list, >> see >> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html > > What is the conclusion (sorry it was unclear to me)? Drop TNSFF for records? > > This issue is to fix the regression introduced by JDK-8255342. I expect > someone else will file a new JBS issue and implement what amber-spec-experts > decided. > >> We already know that the JLS definition of a record will have to be changed for >> inline record (an inline record is not direct subclass of j.l.Record because >> you have the reference projection in the middle). > > Yes I saw that. I updated > [JDK-8251041](https://bugs.openjdk.java.net/browse/JDK-8251041) to follow up. > >> The real issue is that the JIT optimisation and Field.set() should be aligned, >> VarHandle deosn't let you change a final field and Unsafe is unsafe, so the >> current problem is that Field.set() relies on the reflection api by calling >> Class.isRecord() which is not good because Classs.isRecord() returns the JLS >> view of the world not the JVM view of the world. >> >> As said in the mail chain above, for the JIT optimization, instead of listing >> all the new constructs, record, inline, etc, i propose to check the other way, >> only allow to set a final field is only allowed for plain old java class, so >> the VM should not have a method InstanceKlass::is_record but a method that >> return if a class is a plain class or not and this method should be called by >> the JIT and by Field.set (through a JVM entry point) >> so the fact the optimization will be done or not is not related to what the JLS >> think a record is, those are separated concern. > > I agree the current situation is not ideal which requires to declare all the new > constructs explicitly for TNSFF. However, it's a reasonable tradeoff to get > the JIT optimization for records in time while waiting for true TNSFF > investigation like JMM and other relevant specs. I see this just a stop-gap > solution. When the long-term TNSFF is in place, the spec can be updated to > drop the explicit list of record, inline, etc. > > A related issue is > [JDK-8233873](https://bugs.openjdk.java.net/browse/JDK-8233873). I'm happy if > we can do TNSFF in a different solution. > > Again this PR intends to fix the regression. Two options: > 1. Keep [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) and > implement as this proposed patch > 2. Backout [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) > > I expect Chris and/or others will follow up the decision made by the > amber-spec-experts w.r.t. trusting finals in records. I'm okay with either > option. For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. R?mi > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1706 From daniel.peintner at gmail.com Thu Dec 10 14:36:51 2020 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Thu, 10 Dec 2020 15:36:51 +0100 Subject: JNLP In-Reply-To: References: <95564547-8f9f-73ee-278a-7e6c728d9b2b@network-inventory.de> Message-ID: Hello, I am not sure if this is the right list for such kind of discussions but there is also https://openwebstart.com/ Hope this helps, -- Daniel On Thu, Dec 10, 2020 at 3:24 PM Bernd Eckenfels wrote: > Hello, > > We ported a big JWS gui app to stand-alone swing with a home made > installer/update mechanism. This was very easy to do (it had a main method > for debugging anyway). The installer is not the most comfortable, but we > can live with it since the whole application will be replaced by an web app > anyway. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ________________________________ > Von: core-libs-dev im Auftrag von > Thomas Vatter > Gesendet: Thursday, December 10, 2020 1:12:45 PM > An: core-libs-dev at openjdk.java.net > Betreff: JNLP > > I'm using JNLP, how should I go on? > > -- > Network Inventory Software > IBM-Partner, RedHat- und SUSE-Partner, Oracle Technet Member > > www.network-inventory.de > Tel. 030-79782510 > Fax 030-79782512 > E-Mail: thomas.vatter at network-inventory.de > > From chegar at openjdk.java.net Thu Dec 10 14:41:34 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 10 Dec 2020 14:41:34 GMT Subject: RFR: 8257837: Performance regression in heap byte buffer views In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:15:41 GMT, Maurizio Cimadamore wrote: > As a result of the recent integration of the foreign memory access API, some of the buffer implementations now use `ScopedMemoryAccess` instead of `Unsafe`. While this works generally well, there are situations where profile pollution arises, which result in a considerable slowdown. The profile pollution occurs because the same ScopedMemoryAccess method (e.g. `getIntUnaligned`) is called with two different buffer kinds (e.g. an off heap buffer where base == null, and an on-heap buffer where base == byte[]). Because of that, unsafe access cannot be optimized, since C2 can't guess what the unsafe base access is. > > In reality, this problem was already known (and solved) elsewhere: the sun.misc.Unsafe wrapper does basically the same thing that ScopedMemoryAccess does. To make sure that profile pollution does not occur in those cases, argument profiling is enabled for sun.misc.Unsafe as well. This patch adds yet another case for ScopedMemoryAccess. > > Here are the benchmark results: > > Before: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.612 ? 0.005 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 2.740 ? 0.039 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.504 ? 0.020 ms/op > > After > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.613 ? 0.007 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 0.304 ? 0.002 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.491 ? 0.004 ms/op Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1733 From roland at openjdk.java.net Thu Dec 10 14:48:34 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Thu, 10 Dec 2020 14:48:34 GMT Subject: RFR: 8257837: Performance regression in heap byte buffer views In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:15:41 GMT, Maurizio Cimadamore wrote: > As a result of the recent integration of the foreign memory access API, some of the buffer implementations now use `ScopedMemoryAccess` instead of `Unsafe`. While this works generally well, there are situations where profile pollution arises, which result in a considerable slowdown. The profile pollution occurs because the same ScopedMemoryAccess method (e.g. `getIntUnaligned`) is called with two different buffer kinds (e.g. an off heap buffer where base == null, and an on-heap buffer where base == byte[]). Because of that, unsafe access cannot be optimized, since C2 can't guess what the unsafe base access is. > > In reality, this problem was already known (and solved) elsewhere: the sun.misc.Unsafe wrapper does basically the same thing that ScopedMemoryAccess does. To make sure that profile pollution does not occur in those cases, argument profiling is enabled for sun.misc.Unsafe as well. This patch adds yet another case for ScopedMemoryAccess. > > Here are the benchmark results: > > Before: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.612 ? 0.005 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 2.740 ? 0.039 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.504 ? 0.020 ms/op > > After > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.613 ? 0.007 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 0.304 ? 0.002 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.491 ? 0.004 ms/op Marked as reviewed by roland (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1733 From mcimadamore at openjdk.java.net Thu Dec 10 15:35:37 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Dec 2020 15:35:37 GMT Subject: Integrated: 8257837: Performance regression in heap byte buffer views In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:15:41 GMT, Maurizio Cimadamore wrote: > As a result of the recent integration of the foreign memory access API, some of the buffer implementations now use `ScopedMemoryAccess` instead of `Unsafe`. While this works generally well, there are situations where profile pollution arises, which result in a considerable slowdown. The profile pollution occurs because the same ScopedMemoryAccess method (e.g. `getIntUnaligned`) is called with two different buffer kinds (e.g. an off heap buffer where base == null, and an on-heap buffer where base == byte[]). Because of that, unsafe access cannot be optimized, since C2 can't guess what the unsafe base access is. > > In reality, this problem was already known (and solved) elsewhere: the sun.misc.Unsafe wrapper does basically the same thing that ScopedMemoryAccess does. To make sure that profile pollution does not occur in those cases, argument profiling is enabled for sun.misc.Unsafe as well. This patch adds yet another case for ScopedMemoryAccess. > > Here are the benchmark results: > > Before: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.612 ? 0.005 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 2.740 ? 0.039 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.504 ? 0.020 ms/op > > After > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.613 ? 0.007 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 0.304 ? 0.002 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.491 ? 0.004 ms/op This pull request has now been integrated. Changeset: 37043b05 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/37043b05 Stats: 121 lines in 3 files changed: 120 ins; 0 del; 1 mod 8257837: Performance regression in heap byte buffer views Reviewed-by: chegar, roland ------------- PR: https://git.openjdk.java.net/jdk/pull/1733 From redestad at openjdk.java.net Thu Dec 10 16:01:41 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 10 Dec 2020 16:01:41 GMT Subject: RFR: 8257837: Performance regression in heap byte buffer views In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:15:41 GMT, Maurizio Cimadamore wrote: > As a result of the recent integration of the foreign memory access API, some of the buffer implementations now use `ScopedMemoryAccess` instead of `Unsafe`. While this works generally well, there are situations where profile pollution arises, which result in a considerable slowdown. The profile pollution occurs because the same ScopedMemoryAccess method (e.g. `getIntUnaligned`) is called with two different buffer kinds (e.g. an off heap buffer where base == null, and an on-heap buffer where base == byte[]). Because of that, unsafe access cannot be optimized, since C2 can't guess what the unsafe base access is. > > In reality, this problem was already known (and solved) elsewhere: the sun.misc.Unsafe wrapper does basically the same thing that ScopedMemoryAccess does. To make sure that profile pollution does not occur in those cases, argument profiling is enabled for sun.misc.Unsafe as well. This patch adds yet another case for ScopedMemoryAccess. > > Here are the benchmark results: > > Before: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.612 ? 0.005 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 2.740 ? 0.039 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.504 ? 0.020 ms/op > > After > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedBuffer.direct_byte_buffer_get_float avgt 30 0.613 ? 0.007 ms/op > LoopOverPollutedBuffer.heap_byte_buffer_get_int avgt 30 0.304 ? 0.002 ms/op > LoopOverPollutedBuffer.unsafe_get_float avgt 30 0.491 ? 0.004 ms/op src/hotspot/share/oops/methodData.cpp line 1593: > 1591: ResourceMark rm; > 1592: char* name = inv.name()->as_C_string(); > 1593: if (!strncmp(name, "get", 3) || !strncmp(name, "put", 3)) { Pre-existing, but `!strncmp(name, "get", 3)` seem a very circumspect way of writing `inv->name()->starts_with("get")` - which shouldn't need a `ResourceMark` either. Another observation is that `inv.klass()` isn't inlined (defined in bytecode.cpp), so introducing a local for `inv.klass()` avoids multiple calls. How about this: if (inv.is_invokevirtual()) { Symbol* klass = inv.klass(); if (klass == vmSymbols::jdk_internal_misc_Unsafe() || klass == vmSymbols::sun_misc_Unsafe() || klass == vmSymbols::jdk_internal_misc_ScopedMemoryAccess()) { Symbol* name = inv.name(); if (name->starts_with("get") || name->starts_with("put")) { return true; } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/1733 From aph at openjdk.java.net Thu Dec 10 16:10:36 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 10 Dec 2020 16:10:36 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:55:25 GMT, Jorn Vernee wrote: > Thanks for the amazing work! > > FWIW, on x86 RBP was being passed as debug info (see last line in MachCallNode::in_RegMask), so the solution Vlad I proposed would be to override MachCallNativeNode::in_RegMask to not include it IIRC. I haven't had time to look into it yet though. > > The situation on AArch64 seems to be different though? The RFP is not passed as debug info but as part of the normal calling convention maybe? On AArch64 JIT-compiled code, RFP is a callee-saved register that's free for any use. It's very useful for a spilled value across calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From hseigel at openjdk.java.net Thu Dec 10 16:31:33 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 16:31:33 GMT Subject: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 17:48:01 GMT, Severin Gehwolf wrote: > This has been implemented for cgroups v1 with [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was lacking some tooling support for cgroups v2. With podman 2.2.0 release this could now be implemented (and tested). The idea is the same as for the cgroups v1 fix. If we've got no swap limit capabilities, return the memory limit only. > > Note that for cgroups v2 doesn't implement CgroupV1Metrics (obviously) and, thus, doesn't have `getMemoryAndSwapFailCount()` and `getMemoryAndSwapMaxUsage()`. > > Testing: > - [x] submit testing > - [x] container tests on cgroups v2 with swapaccount=0. > - [x] Manual container tests involving `-XshowSettings:system` on cgroups v2. > > Thoughts? The changes look good. Thanks for doing this. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1672 From prappo at openjdk.java.net Thu Dec 10 16:45:36 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 10 Dec 2020 16:45:36 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements [v2] In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 08:35:20 GMT, John Lin wrote: >> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Testing >> >> | | Linux x64 | Windows x64 | macOS x64 | >> | --- | ----- | ----- | ----- | >> | Build | ?? (5/5 passed) | ?? (2/2 passed) | ?? (2/2 passed) | >> | Test (tier1) | ?? (9/9 passed) | ?? (9/9 passed) | ?? (9/9 passed) | >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714` >> `$ git checkout pull/714` > > John Lin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8247402: Documentation for Map::compute contains confusing implementation requirements This looks good to me. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/714 From sgehwolf at openjdk.java.net Thu Dec 10 16:48:31 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 10 Dec 2020 16:48:31 GMT Subject: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 16:28:59 GMT, Harold Seigel wrote: > The changes look good. Thanks for doing this. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1672 From sgehwolf at openjdk.java.net Thu Dec 10 16:51:59 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 10 Dec 2020 16:51:59 GMT Subject: Integrated: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems In-Reply-To: References: Message-ID: <7xEphGBTI5a0xuHWOk4FJqu1PXqcvJUfNFjef3f23hI=.7e7a7528-3caa-4a3b-8c12-a329871c215e@github.com> On Mon, 7 Dec 2020 17:48:01 GMT, Severin Gehwolf wrote: > This has been implemented for cgroups v1 with [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was lacking some tooling support for cgroups v2. With podman 2.2.0 release this could now be implemented (and tested). The idea is the same as for the cgroups v1 fix. If we've got no swap limit capabilities, return the memory limit only. > > Note that for cgroups v2 doesn't implement CgroupV1Metrics (obviously) and, thus, doesn't have `getMemoryAndSwapFailCount()` and `getMemoryAndSwapMaxUsage()`. > > Testing: > - [x] submit testing > - [x] container tests on cgroups v2 with swapaccount=0. > - [x] Manual container tests involving `-XshowSettings:system` on cgroups v2. > > Thoughts? This pull request has now been integrated. Changeset: 66936111 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/66936111 Stats: 45 lines in 2 files changed: 24 ins; 1 del; 20 mod 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/1672 From darcy at openjdk.java.net Thu Dec 10 16:52:13 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Dec 2020 16:52:13 GMT Subject: Integrated: 8257450: Start of release updates for JDK 17 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. This pull request has now been integrated. Changeset: 6be1f567 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/6be1f567 Stats: 7607 lines in 77 files changed: 7548 ins; 0 del; 59 mod 8257450: Start of release updates for JDK 17 8257451: Add SourceVersion.RELEASE_17 8257453: Add source 17 and target 17 to javac Reviewed-by: dholmes, erikj, iris, mikael, jjg, jlahoda, jwilhelm, mchung, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/1531 From bpb at openjdk.java.net Thu Dec 10 17:28:03 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Dec 2020 17:28:03 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array Message-ID: Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. ------------- Commit messages: - 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array Changes: https://git.openjdk.java.net/jdk/pull/1737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248383 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1737/head:pull/1737 PR: https://git.openjdk.java.net/jdk/pull/1737 From martin at openjdk.java.net Thu Dec 10 18:01:58 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Thu, 10 Dec 2020 18:01:58 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements [v2] In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 08:35:20 GMT, John Lin wrote: >> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Testing >> >> | | Linux x64 | Windows x64 | macOS x64 | >> | --- | ----- | ----- | ----- | >> | Build | ?? (5/5 passed) | ?? (2/2 passed) | ?? (2/2 passed) | >> | Test (tier1) | ?? (9/9 passed) | ?? (9/9 passed) | ?? (9/9 passed) | >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714` >> `$ git checkout pull/714` > > John Lin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8247402: Documentation for Map::compute contains confusing implementation requirements Marked as reviewed by martin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From mcimadamore at openjdk.java.net Thu Dec 10 18:27:58 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Dec 2020 18:27:58 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: <_mr07yfBTKU0i01l9adQwv72nO3GF_6zXYbTcGSK87o=.cc6164a4-a518-4155-a6ec-4e570133965d@github.com> On Thu, 10 Dec 2020 09:15:47 GMT, Nick Gasson wrote: >> This is more-or-less a straight port of the x86 code to AArch64. >> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() >> to generate a blob that jumps to the native function entry point. This >> simply switches the thread state from Java to native and handles the >> safepoint poll on return from native code. >> >> AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame >> pointer) may hold a live oop over the MachCallNative node. Normally this >> would be saved by RegisterSaver::save_live_registers() but the native >> invoker blob is not a "proper" stub routine so doesn't have an oop map. >> I copied the x86 solution to this where the frame pointer register is >> saved to the stack and a pointer to that is stored in the frame anchor. >> This is then read back and added to the register map when walking the >> stack. I saw in the PR comments [1] that this might be a temporary fix, >> but I'm not sure if there's any plan to change that now? >> >> Another potential fix might be to change the C2 register definition of >> R29 and R29_H to be save-on-call as below. This works for the >> TestStackWalk.java test case but I don't know whether it has other >> unintended side-effects. >> >> reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp >> reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); >> >> JMH results from jdk/incubator/foreign/CallOverhead.java to show it's >> working: >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op >> CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op >> CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op >> CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op >> CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op >> CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op >> CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op >> CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op >> CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op >> CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op >> CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op >> CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op >> CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op >> CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op >> CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op >> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op >> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op >> >> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks great - thanks for putting in the effort to do this! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1711 From lancea at openjdk.java.net Thu Dec 10 18:32:00 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 10 Dec 2020 18:32:00 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:22:06 GMT, Brian Burkhalter wrote: > Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. Hi Brian, Are there existing tests that cover the behavior described in the proposed change? ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From bpb at openjdk.java.net Thu Dec 10 18:54:02 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Dec 2020 18:54:02 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array In-Reply-To: References: Message-ID: <3okWQJetF5kf4FfQPa-4cEtkIIvKUXDbqARhnFzwc-Y=.15ce39be-7cfb-44e5-b495-22e854190a2b@github.com> On Thu, 10 Dec 2020 18:28:54 GMT, Lance Andersen wrote: >> Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. > > Hi Brian, > > Are there existing tests that cover the behavior described in the proposed change? Hi @LanceAndersen. I don't see any tests specific to this issue, but then there are ten Reader classes in `java.io`, seven of which are not abstract. ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From akozlov at openjdk.java.net Thu Dec 10 20:14:57 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 10 Dec 2020 20:14:57 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:27:25 GMT, Phil Race wrote: >> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. > > Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ? > If I read the doc below it is in the 10.10 SDK and later. > https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ @prrace could you look at this? ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From brian.burkhalter at oracle.com Thu Dec 10 20:23:07 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Dec 2020 12:23:07 -0800 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: References: Message-ID: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Hi Philippe, > On Dec 10, 2020, at 12:03 PM, Philippe Marschall wrote: > > I recently came across Reader#read(CharBuffer) and noticed it was > missing an optimization for heap buffers. [?] These seem like good suggestions. > Sorry if this is the wrong mailing list and should go to core-libs-dev > or a different list instead. I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there. Do you have the ability to file an issue? If not, I can do so. Thanks, Brian From pavel.rappo at oracle.com Thu Dec 10 21:02:43 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 10 Dec 2020 21:02:43 +0000 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com> I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314 > On 10 Dec 2020, at 20:23, Brian Burkhalter wrote: > > Hi Philippe, > >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall wrote: >> >> I recently came across Reader#read(CharBuffer) and noticed it was >> missing an optimization for heap buffers. [?] > > These seem like good suggestions. > >> Sorry if this is the wrong mailing list and should go to core-libs-dev >> or a different list instead. > > I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there. > > Do you have the ability to file an issue? If not, I can do so. > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Dec 10 21:04:00 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Dec 2020 13:04:00 -0800 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com> References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com> Message-ID: <4CC9652C-424A-4FCD-B842-075D6F11DBA1@oracle.com> Awesome, Pavel, thanks! Brian > On Dec 10, 2020, at 1:02 PM, Pavel Rappo wrote: > > I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314 > >> [?] >> >> Do you have the ability to file an issue? If not, I can do so. From naoto at openjdk.java.net Thu Dec 10 22:34:01 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Dec 2020 22:34:01 GMT Subject: RFR: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST Message-ID: Hello, Please review the changes to the subject issue. getMinimalDaysInFirstWeek() for Windows has been implemented to suffice the bug claim. ------------- Commit messages: - JDK-8257964 Changes: https://git.openjdk.java.net/jdk/pull/1741/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1741&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257964 Stats: 53 lines in 4 files changed: 50 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1741.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1741/head:pull/1741 PR: https://git.openjdk.java.net/jdk/pull/1741 From mchung at openjdk.java.net Thu Dec 10 22:58:55 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Dec 2020 22:58:55 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 14:13:27 GMT, Chris Hegarty wrote: >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. >> >> I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: >> - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute >> - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > Marked as reviewed by chegar (Reviewer). Hi Remi, > For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. > And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. This reply was before you realized that records are are permanent Java SE 16 feature :-) If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk > And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. It's the implementation details of the core reflection how to determine if a class is a member of another class. The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From mchung at openjdk.java.net Thu Dec 10 23:01:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Dec 2020 23:01:57 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: <9rP40aGY5L27zoeic4iqCENI_ri8j1JHry0Yan0x9hg=.d6bd721e-b716-4a49-821f-9b9fc99dac5b@github.com> On Thu, 10 Dec 2020 22:56:34 GMT, Mandy Chung wrote: >> Marked as reviewed by chegar (Reviewer). > > Hi Remi, > >> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. >> And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. > > This reply was before you realized that records are are permanent Java SE 16 feature :-) If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk > >> And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. > > It's the implementation details of the core reflection how to determine if a class is a member of another class. The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class. I have created a new branch off jdk16: https://github.com/mlchung/jdk16/tree/8257596. It fixed the attribute name as Harold pointed out. @hseigel tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From naoto at openjdk.java.net Thu Dec 10 23:10:57 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Dec 2020 23:10:57 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> 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. >> >> ### Modules reviewed >> >> - [ ] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [ ] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Move to share/data, and move jdwp.spec to java.se Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall. test/jdk/java/util/Locale/LSRDataTest.java line 57: > 55: // path to the lsr file from the make folder, this test relies on the > 56: // relative path to the file in the make folder, considering > 57: // test and make will always exist in the same jdk layout The comment refers to the "make" folder. (line 55 as well). ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Thu Dec 10 23:15:55 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Dec 2020 23:15:55 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:22:06 GMT, Brian Burkhalter wrote: > Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. Looks good to me, Brian. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1737 From bpb at openjdk.java.net Thu Dec 10 23:29:19 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Dec 2020 23:29:19 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v2] In-Reply-To: References: Message-ID: > Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'JDK-8248383-Reader-read' of https://github.com/bplb/jdk into JDK-8248383-Reader-read - 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array - 8248383: Add test ReadIntoZeroLengthArray - 8248383: Fix alignment of @see tags - 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1737/files - new: https://git.openjdk.java.net/jdk/pull/1737/files/0dc2e243..d8497f0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=00-01 Stats: 35454 lines in 901 files changed: 26596 ins; 5818 del; 3040 mod Patch: https://git.openjdk.java.net/jdk/pull/1737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1737/head:pull/1737 PR: https://git.openjdk.java.net/jdk/pull/1737 From bpb at openjdk.java.net Thu Dec 10 23:29:21 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Dec 2020 23:29:21 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 23:12:57 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'JDK-8248383-Reader-read' of https://github.com/bplb/jdk into JDK-8248383-Reader-read >> - 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array >> - 8248383: Add test ReadIntoZeroLengthArray >> - 8248383: Fix alignment of @see tags >> - 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array > > Looks good to me, Brian. For the sake of sanity I added a minimal test to verify that the behavior is in fact in accord with the added verbiage. ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From bpb at openjdk.java.net Thu Dec 10 23:36:13 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Dec 2020 23:36:13 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v3] In-Reply-To: References: Message-ID: <6MYyTjgru79pTvvR26CIk-Tzo0s_dDgSSbXWUCnfdtk=.0e21f25d-01ba-431b-ac7d-a80c96d488c0@github.com> > Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8248383: Re-indent subclasses in @see tages ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1737/files - new: https://git.openjdk.java.net/jdk/pull/1737/files/d8497f0f..7fbc77f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1737/head:pull/1737 PR: https://git.openjdk.java.net/jdk/pull/1737 From github.com+1290376+johnlinp at openjdk.java.net Fri Dec 11 00:14:57 2020 From: github.com+1290376+johnlinp at openjdk.java.net (John Lin) Date: Fri, 11 Dec 2020 00:14:57 GMT Subject: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements [v2] In-Reply-To: References: Message-ID: <5Fu5wyXPR_OQAxscGBA90hMvkbkVqdjCgEuk_yp9slk=.95ee44eb-228f-4130-a98a-62db99cad674@github.com> On Thu, 10 Dec 2020 17:59:03 GMT, Martin Buchholz wrote: >> John Lin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8247402: Documentation for Map::compute contains confusing implementation requirements > > Marked as reviewed by martin (Reviewer). Thank you all for the review and discussion. This is my first time contributing code in jdk, and it's a really nice experience. ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From github.com+1290376+johnlinp at openjdk.java.net Fri Dec 11 00:28:58 2020 From: github.com+1290376+johnlinp at openjdk.java.net (John Lin) Date: Fri, 11 Dec 2020 00:28:58 GMT Subject: Integrated: 8247402: Documentation for Map::compute contains confusing implementation requirements In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 02:50:28 GMT, John Lin wrote: > This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Testing > > | | Linux x64 | Windows x64 | macOS x64 | > | --- | ----- | ----- | ----- | > | Build | ?? (5/5 passed) | ?? (2/2 passed) | ?? (2/2 passed) | > | Test (tier1) | ?? (9/9 passed) | ?? (9/9 passed) | ?? (9/9 passed) | > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714` > `$ git checkout pull/714` This pull request has now been integrated. Changeset: 37dc675c Author: John Lin Committer: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/37dc675c Stats: 13 lines in 1 file changed: 1 ins; 7 del; 5 mod 8247402: Documentation for Map::compute contains confusing implementation requirements Reviewed-by: prappo, martin ------------- PR: https://git.openjdk.java.net/jdk/pull/714 From joehw at openjdk.java.net Fri Dec 11 00:28:59 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 11 Dec 2020 00:28:59 GMT Subject: RFR: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 21:12:29 GMT, Naoto Sato wrote: > Hello, > > Please review the changes to the subject issue. getMinimalDaysInFirstWeek() for Windows has been implemented to suffice the bug claim. Looks good to me. Some minor comments below. src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java line 78: > 76: // CalendarData value types > 77: private static final int CD_FIRSTDAYOFWEEK = 0; > 78: private static final int CD_MINIMALDAYSINFIRSTWEEK = 1; Do we want to keep the naming consistent, doing the same change to, e.g. the corresponding macosx impl? src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java line 373: > 371: CD_FIRSTWEEKOFYEAR); > 372: return switch (firstWeek) { > 373: case 1 -> 7; Would it be good to use constants or enum instead of literal, or maybe at least a note for the case numbers. test/jdk/java/util/Locale/LocaleProvidersRun.java line 177: > 175: > 176: //testing 8257964 fix. (macOS/Windows only) > 177: testRun("HOST", "bug8257964Test", "", "", ""); This test runs only if the platform locale is en-GB. Do we know if the test system run tests on multiple locales? From the console output unfortunately, it's impossible to tell which specific tests were run ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1741 From naoto at openjdk.java.net Fri Dec 11 01:25:09 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Dec 2020 01:25:09 GMT Subject: RFR: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST [v2] In-Reply-To: References: Message-ID: > Hello, > > Please review the changes to the subject issue. getMinimalDaysInFirstWeek() for Windows has been implemented to suffice the bug claim. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added comment for LOCALE_IFIRSTWEEKOFYEAR Windows return values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1741/files - new: https://git.openjdk.java.net/jdk/pull/1741/files/a9ea9f16..3f40c3db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1741&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1741&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1741.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1741/head:pull/1741 PR: https://git.openjdk.java.net/jdk/pull/1741 From naoto at openjdk.java.net Fri Dec 11 01:32:00 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Dec 2020 01:32:00 GMT Subject: RFR: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 00:15:49 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment for LOCALE_IFIRSTWEEKOFYEAR Windows return values > > src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java line 78: > >> 76: // CalendarData value types >> 77: private static final int CD_FIRSTDAYOFWEEK = 0; >> 78: private static final int CD_MINIMALDAYSINFIRSTWEEK = 1; > > Do we want to keep the naming consistent, doing the same change to, e.g. the corresponding macosx impl? The constants are for native methods, which differ between macOS and Windows. Thus I thought it would be clearer to align the name with Windows' constants. > src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java line 373: > >> 371: CD_FIRSTWEEKOFYEAR); >> 372: return switch (firstWeek) { >> 373: case 1 -> 7; > > Would it be good to use constants or enum instead of literal, or maybe at least a note for the case numbers. Could be better by making them as enums, but there are other locations similarly using ints. I added extra comments to explain those ints for better readability. > test/jdk/java/util/Locale/LocaleProvidersRun.java line 177: > >> 175: >> 176: //testing 8257964 fix. (macOS/Windows only) >> 177: testRun("HOST", "bug8257964Test", "", "", ""); > > This test runs only if the platform locale is en-GB. Do we know if the test system run tests on multiple locales? From the console output unfortunately, it's impossible to tell which specific tests were run Could be, but it is enough to test one locale to demonstrate platform settings are used for minimal days in first week. Each test case name can be found in the command line to the java launcher which is logged in the .jtr file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1741 From joehw at openjdk.java.net Fri Dec 11 01:51:59 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 11 Dec 2020 01:51:59 GMT Subject: RFR: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST [v2] In-Reply-To: References: Message-ID: <4IqvkTU7FX88uvBY51wF07mQTqOTWSG6u1AvJn6H9ak=.f6467f18-f73e-4acc-9384-928fe14ee5f1@github.com> On Fri, 11 Dec 2020 01:25:48 GMT, Naoto Sato wrote: >> src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java line 78: >> >>> 76: // CalendarData value types >>> 77: private static final int CD_FIRSTDAYOFWEEK = 0; >>> 78: private static final int CD_MINIMALDAYSINFIRSTWEEK = 1; >> >> Do we want to keep the naming consistent, doing the same change to, e.g. the corresponding macosx impl? > > The constants are for native methods, which differ between macOS and Windows. Thus I thought it would be clearer to align the name with Windows' constants. Make sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/1741 From vromero at openjdk.java.net Fri Dec 11 02:13:10 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 02:13:10 GMT Subject: RFR: 8257598: Clarify what component values are used in Record::equals Message-ID: Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. TIA, Vicente ------------- Commit messages: - Merge branch 'master' into JDK-8257598 - Merge branch 'master' into JDK-8257598 - 8257598: Clarify what component values are used in Record::equals Changes: https://git.openjdk.java.net/jdk/pull/1742/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1742&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257598 Stats: 135 lines in 2 files changed: 132 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1742.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1742/head:pull/1742 PR: https://git.openjdk.java.net/jdk/pull/1742 From joe.darcy at oracle.com Fri Dec 11 02:25:46 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 10 Dec 2020 18:25:46 -0800 Subject: RFR: 8257598: Clarify what component values are used in Record::equals In-Reply-To: References: Message-ID: If this is meant for JDK 16, it is easier overall if PR is done against the JDK 16 repo. -Joe On 12/10/2020 6:13 PM, Vicente Romero wrote: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente > > ------------- > > Commit messages: > - Merge branch 'master' into JDK-8257598 > - Merge branch 'master' into JDK-8257598 > - 8257598: Clarify what component values are used in Record::equals > > Changes: https://git.openjdk.java.net/jdk/pull/1742/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1742&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8257598 > Stats: 135 lines in 2 files changed: 132 ins; 1 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/1742.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1742/head:pull/1742 > > PR: https://git.openjdk.java.net/jdk/pull/1742 From vromero at openjdk.java.net Fri Dec 11 04:30:55 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 04:30:55 GMT Subject: Withdrawn: 8257598: Clarify what component values are used in Record::equals In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 02:07:50 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1742 From vromero at openjdk.java.net Fri Dec 11 05:08:06 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 05:08:06 GMT Subject: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals Message-ID: Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. TIA, Vicente ------------- Commit messages: - 8257598: Clarify what component values are used in Record::equals Changes: https://git.openjdk.java.net/jdk16/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257598 Stats: 135 lines in 2 files changed: 132 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/5/head:pull/5 PR: https://git.openjdk.java.net/jdk16/pull/5 From vromero at openjdk.java.net Fri Dec 11 05:10:56 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 05:10:56 GMT Subject: RFR: 8257598: Clarify what component values are used in Record::equals In-Reply-To: References: Message-ID: <1B_KxwxC3jwpR81YMnTx0wXkrAKiip7CI9K19IYaeFQ=.b5403b79-538b-4111-b3c9-8f8ae7c3e496@github.com> On Fri, 11 Dec 2020 02:07:50 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente > _Mailing list message from [Joe Darcy](mailto:joe.darcy at oracle.com) on [compiler-dev](mailto:compiler-dev at openjdk.java.net):_ > > If this is meant for JDK 16, it is easier overall if PR is done against > the JDK 16 repo. > > -Joe > > On 12/10/2020 6:13 PM, Vicente Romero wrote: true, thanks, I have created another PR based on jdk16: https://github.com/openjdk/jdk16/pull/5 ------------- PR: https://git.openjdk.java.net/jdk/pull/1742 From minqi at openjdk.java.net Fri Dec 11 05:17:33 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 11 Dec 2020 05:17:33 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v5] In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. > The fix is the first step of two steps: > 1) Do not split reserved memory; > 2) Remove splitting memory. > This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: - Added test case; Fixed an nmt issue caused by bitmap region not released after archive loading failed; Unmap bitmap after archive failure. Fixed reserved region name for adding reserved region. - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test. - 8253762: JFR: getField(String) should be able to access subfields Reviewed-by: mgronlun - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks Reviewed-by: jnimeh - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32 Reviewed-by: kvn - 8257211: C2: Enable call devirtualization during post-parse phase Reviewed-by: kvn, neliasso, thartmann - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Reviewed-by: ihse, alanb, dcubed, erikj - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs Reviewed-by: redestad, kvn - 8257799: Update JLS cross-references in java.compiler Reviewed-by: jjg - 8254939: macOS: unused function 'replicate4_imm' Reviewed-by: redestad, thartmann - ... and 25 more: https://git.openjdk.java.net/jdk/compare/29a09c89...0421943d ------------- Changes: https://git.openjdk.java.net/jdk/pull/1657/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=04 Stats: 8183 lines in 159 files changed: 4666 ins; 2763 del; 754 mod Patch: https://git.openjdk.java.net/jdk/pull/1657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657 PR: https://git.openjdk.java.net/jdk/pull/1657 From darcy at openjdk.java.net Fri Dec 11 05:17:58 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Dec 2020 05:17:58 GMT Subject: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 05:02:25 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente Looks fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/5 From minqi at openjdk.java.net Fri Dec 11 06:20:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 11 Dec 2020 06:20:56 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v5] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi wrote: >> Changes requested by iklam (Reviewer). > > Please check 03. 02 is generated when merge with most current and remote head not updated correctly. After set remote head correct, 03 is regenerated and is correct one for review. Thanks This branch has many conflicts, something wrong since push-02, closed this PR and will send a single patch in new PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From minqi at openjdk.java.net Fri Dec 11 06:20:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 11 Dec 2020 06:20:57 GMT Subject: Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: <9Hu8Jqsqm4gG7-yV0AZIZvnOh72CmunbbQhdT-LnjBA=.da14a187-fb1b-4190-9e4b-d06896ad7202@github.com> On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi wrote: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. > The fix is the first step of two steps: > 1) Do not split reserved memory; > 2) Remove splitting memory. > This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From ngasson at openjdk.java.net Fri Dec 11 07:42:19 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 11 Dec 2020 07:42:19 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v3] In-Reply-To: References: Message-ID: <3a5slI0Zl90wUdV51eoccwUjFaWAx4MVW0uf-P2Uv3Y=.b581e478-928e-40c3-aa5f-6d439b22c94e@github.com> > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Separate RegSet and FloatRegSet - Merge branch 'master' into 8257882 - Review comments - 8257882: Implement linkToNative intrinsic on AArch64 This is more-or-less a straight port of the x86 code to AArch64. GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() to generate a blob that jumps to the native function entry point. This simply switches the thread state from Java to native and handles the safepoint poll on return from native code. AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame pointer) may hold a live oop over the MachCallNative node. Normally this would be saved by RegisterSaver::save_live_registers() but the native invoker blob is not a "proper" stub routine so doesn't have an oop map. I copied the x86 solution to this where the frame pointer register is saved to the stack and a pointer to that is stored in the frame anchor. This is then read back and added to the register map when walking the stack. I saw in the PR comments [1] that this might be a temporary fix, but I'm not sure if there's any plan to change that now? Another potential fix might be to change the C2 register definition of R29 and R29_H to be save-on-call as below. This works for the TestStackWalk.java test case but I don't know whether it has other unintended side-effects. reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); JMH results from jdk/incubator/foreign/CallOverhead.java to show it's working: -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: Benchmark Mode Cnt Score Error Units CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: Benchmark Mode Cnt Score Error Units CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1711/files - new: https://git.openjdk.java.net/jdk/pull/1711/files/99390b92..d7915ff7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=01-02 Stats: 16236 lines in 388 files changed: 13679 ins; 1669 del; 888 mod Patch: https://git.openjdk.java.net/jdk/pull/1711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1711/head:pull/1711 PR: https://git.openjdk.java.net/jdk/pull/1711 From ngasson at openjdk.java.net Fri Dec 11 07:42:20 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 11 Dec 2020 07:42:20 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: <8Rb_HLmKbV8ABX61dH_EE9YVIRAm7OVWOe0hyxsn00A=.34cd37c2-ea2c-4a24-b2b9-fb42459e3f56@github.com> Message-ID: On Thu, 10 Dec 2020 10:47:48 GMT, Andrew Haley wrote: >> Should we have a separate RegSet type for FloatRegisters to avoid mixing them up? > > Absolutely. I'd make an AbstractRegSet and use it as a base type > for both RegSet and FloatRegSet, then we can get rid of the casts > altogether. OK I've done that in the latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From ngasson at openjdk.java.net Fri Dec 11 07:42:21 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 11 Dec 2020 07:42:21 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:45:21 GMT, Jorn Vernee wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3104: > >> 3102: const GrowableArray& output_registers) { >> 3103: BufferBlob* _invoke_native_blob = >> 3104: BufferBlob::create("nep_invoker_blob", MethodHandles::adapter_code_size); > > That reminds me; this should _not_ use MethodHandles::adapter_code_size, but a separate constant, since the former is tailored specifically to method handle stubs (and is too large for this case). I still need to update the one for x86 as well (looks like I forgot to do that one before when I changed them for invoker/upcall handler). I think 1024 bytes should be more than enough, but would need to test it. I've changed it to 1024 for AArch64, definitely large enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From aph at openjdk.java.net Fri Dec 11 09:38:01 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 11 Dec 2020 09:38:01 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v3] In-Reply-To: <3a5slI0Zl90wUdV51eoccwUjFaWAx4MVW0uf-P2Uv3Y=.b581e478-928e-40c3-aa5f-6d439b22c94e@github.com> References: <3a5slI0Zl90wUdV51eoccwUjFaWAx4MVW0uf-P2Uv3Y=.b581e478-928e-40c3-aa5f-6d439b22c94e@github.com> Message-ID: <_xKfCmJj_9WoZWAniJihNjn5YtpLXvYLgexXMLmpzBQ=.9b4e6a37-2ec3-4cc2-91f7-5df49aa06f35@github.com> On Fri, 11 Dec 2020 07:42:19 GMT, Nick Gasson wrote: >> This is more-or-less a straight port of the x86 code to AArch64. >> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() >> to generate a blob that jumps to the native function entry point. This >> simply switches the thread state from Java to native and handles the >> safepoint poll on return from native code. >> >> AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame >> pointer) may hold a live oop over the MachCallNative node. Normally this >> would be saved by RegisterSaver::save_live_registers() but the native >> invoker blob is not a "proper" stub routine so doesn't have an oop map. >> I copied the x86 solution to this where the frame pointer register is >> saved to the stack and a pointer to that is stored in the frame anchor. >> This is then read back and added to the register map when walking the >> stack. I saw in the PR comments [1] that this might be a temporary fix, >> but I'm not sure if there's any plan to change that now? >> >> Another potential fix might be to change the C2 register definition of >> R29 and R29_H to be save-on-call as below. This works for the >> TestStackWalk.java test case but I don't know whether it has other >> unintended side-effects. >> >> reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp >> reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); >> >> JMH results from jdk/incubator/foreign/CallOverhead.java to show it's >> working: >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op >> CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op >> CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op >> CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op >> CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op >> CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op >> CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op >> CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op >> CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op >> CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op >> CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op >> CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op >> CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op >> CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op >> CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op >> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op >> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op >> >> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 > > Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Separate RegSet and FloatRegSet > - Merge branch 'master' into 8257882 > - Review comments > - 8257882: Implement linkToNative intrinsic on AArch64 > > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3140: > 3138: // State transition > 3139: __ mov(rscratch1, _thread_in_native); > 3140: __ strw(rscratch1, Address(rthread, JavaThread::thread_state_offset())); I think this should be a releasing store. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3159: > 3157: > 3158: __ safepoint_poll(L_safepoint_poll_slow_path, rthread, true /* at_return */, false /* in_nmethod */); > 3159: This looks wrong: please look at the definition of MacroAssembler::safepoint_poll, which has an acquire flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From chegar at openjdk.java.net Fri Dec 11 09:46:55 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 11 Dec 2020 09:46:55 GMT Subject: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 05:02:25 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente The change and test look good to me. Thanks Vicente. I have just one minor comment on the location of the test. I know there is not always a clear and clean separation across component areas, but another possible location, for your consideration, is test/jdk/java/lang/reflect/record - which contains other runtime tests for records. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/5 From iignatyev at openjdk.java.net Fri Dec 11 13:50:58 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 11 Dec 2020 13:50:58 GMT Subject: RFR: 8166026: Refactor java/lang shell tests to java [v3] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 15:19:58 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java Changes requested by iignatyev (Reviewer). test/jdk/java/lang/annotation/LoaderLeakTest.java line 79: > 77: .directory(Paths.get(Utils.TEST_CLASSES).toFile() > 78: ) > 79: ).shouldHaveExitValue(0); indentation here looks wierd test/jdk/java/lang/annotation/LoaderLeakTest.java line 54: > 52: List classes = List.of("A.class", "B.class", "C.class"); > 53: for (String fileName : classes) { > 54: Files.move( I don't think it's a good idea to move files created and managed by `jtreg`. I'd recommend you copying them here and, in `runJavaProcess...` constructing `ProcessBuilder` youself: var args = new ArrayList(command.length + 1); args.add(JDKToolFinder.getJDKTool("java")); Collections.addAll(args, command); var pb = new ProcessBuilder(args).directory(Paths.get(Utils.TEST_CLASSES).toFile()); ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From isipka at openjdk.java.net Fri Dec 11 14:39:57 2020 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Fri, 11 Dec 2020 14:39:57 GMT Subject: Integrated: 8166026: Refactor java/lang shell tests to java In-Reply-To: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> References: <0QmU1hx7L1RiCORISp2sHwNglzRA3mDPzfADF_FMz8w=.a0addff4-e150-44f1-a2e1-19de45f4d890@github.com> Message-ID: On Wed, 2 Dec 2020 20:45:11 GMT, Ivan ?ipka wrote: > Refactor `test/jdk/java/lang/SecurityManager/modules/CustomSecurityManager.sh` as java test. This pull request has now been integrated. Changeset: 82735140 Author: Ivan ?ipka Committer: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/82735140 Stats: 184 lines in 3 files changed: 84 ins; 100 del; 0 mod 8166026: Refactor java/lang shell tests to java Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/1579 From github.com+1746404+janecekpetr at openjdk.java.net Fri Dec 11 15:11:56 2020 From: github.com+1746404+janecekpetr at openjdk.java.net (Petr =?UTF-8?B?SmFuZcSNZWs=?=) Date: Fri, 11 Dec 2020 15:11:56 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 18:41:02 GMT, Pavel Rappo wrote: >> Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> JDK-8234131 > > The changes to doc comments look good. > > Thanks for incorporating my earlier code snippet suggestions published on [concurrency-interest](http://cs.oswego.edu/pipermail/concurrency-interest/2020-November/017264.html)! This also fixes issue [JDK-8257671](https://bugs.openjdk.java.net/browse/JDK-8257671): _ThreadPoolExecutor.Discard*Policy: rejected tasks are not cancelled_, by updating the `TPE.Discard*Policy` JavaDocs. I filed it days before the code went in as I did not see the JavaDoc update in JDK, sorry for my impatience and thank you for the fix. I cannot update the Jira, please link it to this PR, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From vromero at openjdk.java.net Fri Dec 11 15:52:13 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 15:52:13 GMT Subject: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals [v2] In-Reply-To: References: Message-ID: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: moving test to another location ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/5/files - new: https://git.openjdk.java.net/jdk16/pull/5/files/73e8ad5f..566b78d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=5&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=5&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/5/head:pull/5 PR: https://git.openjdk.java.net/jdk16/pull/5 From vromero at openjdk.java.net Fri Dec 11 15:52:13 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 15:52:13 GMT Subject: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 09:44:33 GMT, Chris Hegarty wrote: > The change and test look good to me. Thanks Vicente. > > I have just one minor comment on the location of the test. I know there is not always a clear and clean separation across component areas, but another possible location, for your consideration, is test/jdk/java/lang/reflect/record - which contains other runtime tests for records. thanks for your comments, I have moved the test to another location ------------- PR: https://git.openjdk.java.net/jdk16/pull/5 From dfuchs at openjdk.java.net Fri Dec 11 16:16:07 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 11 Dec 2020 16:16:07 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v19] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:46:54 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with modified parameters. >> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex >> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... >> - Prefix and suffixes now apply to each formatted value, not the string as a whole >> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams >> like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) >> - Immutable and thread safe, a "value-based" class >> >> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. >> >> Review comments and suggestions welcome. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarified parsing of hex as unsigned in fromHexDigits methods. Changes requested by dfuchs (Reviewer). src/java.base/share/classes/java/util/HexFormat.java line 961: > 959: * characters. > 960: * The characters in the range {@code fromIndex} to {@code toIndex}, exclusive, > 961: * are parsed are parsed from most significant to least significant Is there some stuttering here? `are parsed are parsed` ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From brian.burkhalter at oracle.com Fri Dec 11 16:35:00 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Dec 2020 08:35:00 -0800 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: Hello, > On Dec 11, 2020, at 8:31 AM, Philippe Marschall wrote: > >> Do you have the ability to file an issue? If not, I can do so. > > I don't have the ability to file an issue. The bug that Pavel found is > enough for me to work on for now. If you believe pursuing two other > improvements would be worthwhile I could work on them as well if you > file issues for them. I think perhaps they could all go in the same PR as the things are quite related. It would be good to have simple JMH benchmarks to measure the improvements. The benchmark code does not necessarily have to be in the PR, i.e., checked in. Thanks, Brian From dfuchs at openjdk.java.net Fri Dec 11 16:43:00 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 11 Dec 2020 16:43:00 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:51:02 GMT, Mahendra Chhipa wrote: >> jaxp.library.SimpleHttpServer >> https://bugs.openjdk.java.net/browse/JDK-8212035 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the review comments. Changes requested by dfuchs (Reviewer). test/lib/jdk/test/lib/net/SimpleHttpServer.java line 63: > 61: httpServer = HttpServer.create(); > 62: //let the server use wild card address > 63: inetAddress = null; can this constructor simply call `this(null, context, docRoot)` test/lib/jdk/test/lib/net/SimpleHttpServer.java line 83: > 81: //let the server use wild card address > 82: inetAddress = null; > 83: } Ideally, all constructors should all delegate to a single constructor that would do all the assignments. Maybe investigate a constructor that takes an InetSocketAddress (that would contain both InetAddress and port) test/lib/jdk/test/lib/net/SimpleHttpServer.java line 94: > 92: httpServer.setExecutor(executor); > 93: httpServer.start(); > 94: address = "http://localhost:" + httpServer.getAddress().getPort(); It might be a better idea to use the URIBuilder here rather than relying on the local machine configuration to resolve "localhost"; ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From joehw at openjdk.java.net Fri Dec 11 17:46:00 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 11 Dec 2020 17:46:00 GMT Subject: RFR: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 01:28:59 GMT, Naoto Sato wrote: >> test/jdk/java/util/Locale/LocaleProvidersRun.java line 177: >> >>> 175: >>> 176: //testing 8257964 fix. (macOS/Windows only) >>> 177: testRun("HOST", "bug8257964Test", "", "", ""); >> >> This test runs only if the platform locale is en-GB. Do we know if the test system run tests on multiple locales? From the console output unfortunately, it's impossible to tell which specific tests were run > > Could be, but it is enough to test one locale to demonstrate platform settings are used for minimal days in first week. Each test case name can be found in the command line to the java launcher which is logged in the .jtr file. Good to know it's shown in the .jtr file. Let's hope a link to the test result (html) will be provided in the future :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1741 From chegar at openjdk.java.net Fri Dec 11 17:53:57 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 11 Dec 2020 17:53:57 GMT Subject: [jdk16] RFR: 8257598: Clarify what component values are used in Record::equals [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 15:52:13 GMT, Vicente Romero wrote: >> Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. >> >> TIA, >> Vicente > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > moving test to another location Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/5 From mchung at openjdk.java.net Fri Dec 11 18:05:01 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 18:05:01 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes Message-ID: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. ------------- Commit messages: - Fix the attribute name in comments - Merge branch 'master' of https://github.com/openjdk/jdk16 into 8257596 - 8257596: Clarify trusted final fields for record classes Changes: https://git.openjdk.java.net/jdk16/pull/14/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=14&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257596 Stats: 59 lines in 4 files changed: 29 ins; 10 del; 20 mod Patch: https://git.openjdk.java.net/jdk16/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/14/head:pull/14 PR: https://git.openjdk.java.net/jdk16/pull/14 From mchung at openjdk.java.net Fri Dec 11 18:08:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 18:08:56 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: <9rP40aGY5L27zoeic4iqCENI_ri8j1JHry0Yan0x9hg=.d6bd721e-b716-4a49-821f-9b9fc99dac5b@github.com> References: <9rP40aGY5L27zoeic4iqCENI_ri8j1JHry0Yan0x9hg=.d6bd721e-b716-4a49-821f-9b9fc99dac5b@github.com> Message-ID: On Thu, 10 Dec 2020 22:59:16 GMT, Mandy Chung wrote: >> Hi Remi, >> >>> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. >>> And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. >> >> This reply was before you realized that records are are permanent Java SE 16 feature :-) If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk >> >>> And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. >> >> It's the implementation details of the core reflection how to determine if a class is a member of another class. The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class. This indeed needs some investigation what the best way to address this. > > I have created a new branch off jdk16: https://github.com/mlchung/jdk16/tree/8257596. It fixed the attribute name as Harold pointed out. > > @hseigel tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. Target this fix for jdk16 (https://github.com/openjdk/jdk16/pull/14). ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From mchung at openjdk.java.net Fri Dec 11 18:08:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 18:08:57 GMT Subject: Withdrawn: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From hseigel at openjdk.java.net Fri Dec 11 18:41:58 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 11 Dec 2020 18:41:58 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: On Fri, 11 Dec 2020 17:58:33 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. > > See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute > - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. Hi Mandy, The changes look good. Thanks for running the tests and changing the attribute name in the comments. Could you also change the two comments that you added to jvm.c with these comments: Comment for JVM_IsRecord(): // A class is a record if and only if it is final and a direct subclass of // java.lang.Record and has a Record attribute; otherwise, it is not a record. Comment for JVM_GetRecordComponents(): // Returns an array containing the components of the Record attribute, // or NULL if the attribute is not present. // // Note that this function returns the components of the Record attribute // even if the class is not a Record. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/14 From herrick at openjdk.java.net Fri Dec 11 18:43:55 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 11 Dec 2020 18:43:55 GMT Subject: Withdrawn: JDK-8257539: tools/jpackage/windows/WinL10nTest.java unpack.bat failed with Exit code: 1618 In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:29:56 GMT, Andy Herrick wrote: > increase retries and timeout increasing in runMsiexecWithRetries This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1676 From vromero at openjdk.java.net Fri Dec 11 19:19:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Dec 2020 19:19:58 GMT Subject: [jdk16] Integrated: 8257598: Clarify what component values are used in Record::equals In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 05:02:25 GMT, Vicente Romero wrote: > Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors. > > TIA, > Vicente This pull request has now been integrated. Changeset: b7ac32d6 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk16/commit/b7ac32d6 Stats: 135 lines in 2 files changed: 132 ins; 1 del; 2 mod 8257598: Clarify what component values are used in Record::equals Reviewed-by: darcy, chegar ------------- PR: https://git.openjdk.java.net/jdk16/pull/5 From chegar at openjdk.java.net Fri Dec 11 19:24:54 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 11 Dec 2020 19:24:54 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: <3t9sF45mqzVzsTTnDw2I8a7ja4s71cVNdaCHOsAaa4k=.7deb5be8-e437-495a-87e8-207850207f40@github.com> On Fri, 11 Dec 2020 17:58:33 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. > > See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute > - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/14 From mchung at openjdk.java.net Fri Dec 11 19:29:09 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 19:29:09 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes [v2] In-Reply-To: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. > > See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute > - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Update comments in jvm.cpp per Harold's feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/14/files - new: https://git.openjdk.java.net/jdk16/pull/14/files/7deefccc..4ebee9b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=14&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=14&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 5 del; 8 mod Patch: https://git.openjdk.java.net/jdk16/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/14/head:pull/14 PR: https://git.openjdk.java.net/jdk16/pull/14 From hseigel at openjdk.java.net Fri Dec 11 19:31:58 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 11 Dec 2020 19:31:58 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes [v2] In-Reply-To: References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: On Fri, 11 Dec 2020 19:29:09 GMT, Mandy Chung wrote: >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. >> >> See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html >> >> That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: >> - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute >> - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. >> >> tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Update comments in jvm.cpp per Harold's feedback Looks Good! ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/14 From psandoz at openjdk.java.net Fri Dec 11 19:32:00 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 11 Dec 2020 19:32:00 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes [v2] In-Reply-To: References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: On Fri, 11 Dec 2020 19:29:09 GMT, Mandy Chung wrote: >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. >> >> See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html >> >> That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: >> - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute >> - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. >> >> tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Update comments in jvm.cpp per Harold's feedback IIUC, in summary this correctly aligns the runtime definition of a record with the language, which therefore and appropriately constrains the trusting of non-static final fields to only fields of records, and not more broadly to record-like classes. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/14 From mchung at openjdk.java.net Fri Dec 11 19:45:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 19:45:13 GMT Subject: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes [v3] In-Reply-To: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. > > See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute > - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Update comments in Class::getRecordComponents0 ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/14/files - new: https://git.openjdk.java.net/jdk16/pull/14/files/4ebee9b1..f0df17a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=14&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=14&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/14/head:pull/14 PR: https://git.openjdk.java.net/jdk16/pull/14 From github.com+34924738+mahendrachhipa at openjdk.java.net Fri Dec 11 21:01:18 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Fri, 11 Dec 2020 21:01:18 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v3] In-Reply-To: References: Message-ID: > jaxp.library.SimpleHttpServer > https://bugs.openjdk.java.net/browse/JDK-8212035 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemnted the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1632/files - new: https://git.openjdk.java.net/jdk/pull/1632/files/71fc7e9f..54529720 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=01-02 Stats: 81 lines in 4 files changed: 11 ins; 28 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/1632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632 PR: https://git.openjdk.java.net/jdk/pull/1632 From github.com+34924738+mahendrachhipa at openjdk.java.net Fri Dec 11 21:06:00 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Fri, 11 Dec 2020 21:06:00 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 18:01:20 GMT, Daniel Fuchs wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > test/lib/jdk/test/lib/net/SimpleHttpServer.java line 83: > >> 81: //let the server use wild card address >> 82: inetAddress = null; >> 83: } > > Ideally, all constructors should all delegate to a single constructor that would do all the assignments. Maybe investigate a constructor that takes an InetSocketAddress (that would contain both InetAddress and port) Now Constructor takes InetSocketAddress as parameter, so now no need of multiple constructors. Thanks for the advice. > test/lib/jdk/test/lib/net/SimpleHttpServer.java line 63: > >> 61: httpServer = HttpServer.create(); >> 62: //let the server use wild card address >> 63: inetAddress = null; > > can this constructor simply call `this(null, context, docRoot)` Now Constructor takes InetSocketAddress as parameter, so now no need of multiple constructors. Thanks for the advice. ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From github.com+34924738+mahendrachhipa at openjdk.java.net Fri Dec 11 21:23:12 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Fri, 11 Dec 2020 21:23:12 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v4] In-Reply-To: References: Message-ID: > jaxp.library.SimpleHttpServer > https://bugs.openjdk.java.net/browse/JDK-8212035 Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035 - Implemnted the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1632/files - new: https://git.openjdk.java.net/jdk/pull/1632/files/54529720..6f6a3c62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=02-03 Stats: 6 lines in 3 files changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632 PR: https://git.openjdk.java.net/jdk/pull/1632 From naoto at openjdk.java.net Fri Dec 11 21:28:58 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Dec 2020 21:28:58 GMT Subject: Integrated: 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 21:12:29 GMT, Naoto Sato wrote: > Hello, > > Please review the changes to the subject issue. getMinimalDaysInFirstWeek() for Windows has been implemented to suffice the bug claim. This pull request has now been integrated. Changeset: 74b79c6e Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/74b79c6e Stats: 54 lines in 4 files changed: 51 ins; 0 del; 3 mod 8257964: Broken Calendar#getMinimalDaysInFirstWeek with java.locale.providers=HOST Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/1741 From philippe.marschall at gmail.com Fri Dec 11 15:18:04 2020 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Fri, 11 Dec 2020 16:18:04 +0100 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com> References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com> Message-ID: Awesome, I'll work on a PR for this then. Cheers Philippe On Thu, Dec 10, 2020 at 10:04 PM Pavel Rappo wrote: > > I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314 > > > On 10 Dec 2020, at 20:23, Brian Burkhalter wrote: > > > > Hi Philippe, > > > >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall wrote: > >> > >> I recently came across Reader#read(CharBuffer) and noticed it was > >> missing an optimization for heap buffers. [?] > > > > These seem like good suggestions. > > > >> Sorry if this is the wrong mailing list and should go to core-libs-dev > >> or a different list instead. > > > > I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there. > > > > Do you have the ability to file an issue? If not, I can do so. > > > > Thanks, > > > > Brian > From philippe.marschall at gmail.com Fri Dec 11 16:31:30 2020 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Fri, 11 Dec 2020 17:31:30 +0100 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: On Thu, Dec 10, 2020 at 9:25 PM Brian Burkhalter wrote: > > Hi Philippe, > > On Dec 10, 2020, at 12:03 PM, Philippe Marschall wrote: > > ... > > > I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there. Thank you. > Do you have the ability to file an issue? If not, I can do so. I don't have the ability to file an issue. The bug that Pavel found is enough for me to work on for now. If you believe pursuing two other improvements would be worthwhile I could work on them as well if you file issues for them. Cheers Philippe From mchung at openjdk.java.net Fri Dec 11 22:48:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 22:48:57 GMT Subject: [jdk16] Integrated: 8257596: Clarify trusted final fields for record classes In-Reply-To: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> References: <78B6vaz75IBj_ROw8fQSQ1E3EH0332S_z-JLjXVvQtE=.00996203-7b93-4699-848f-6a52878e66e2@github.com> Message-ID: On Fri, 11 Dec 2020 17:58:33 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes. > > See the discussion at https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > That fixes trusting final fields of records to align with the JLS definition of a record class. `InstanceKlass::is_record` is fixed to check a record class must be final and a direct subclass of `java.lang.Record` with the presence of the `Record` attribute. There is no change to JVM class file validation. I also propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `Record` attribute > - `JVM_GetRecordComponents `returns an `RecordComponents` array if `Record` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `Record` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. This pull request has now been integrated. Changeset: 2001da3d Author: Mandy Chung URL: https://git.openjdk.java.net/jdk16/commit/2001da3d Stats: 55 lines in 4 files changed: 25 ins; 10 del; 20 mod 8257596: Clarify trusted final fields for record classes Reviewed-by: hseigel, chegar, psandoz ------------- PR: https://git.openjdk.java.net/jdk16/pull/14 From forax at univ-mlv.fr Sat Dec 12 16:07:32 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 12 Dec 2020 17:07:32 +0100 (CET) Subject: It's not a bug but it's not user friendly Message-ID: <950404544.1998857.1607789252808.JavaMail.zimbra@u-pem.fr> A student of mine send me a code that can be reduced to this code --- import java.lang.invoke.MethodHandles; import java.lang.invoke.VarHandle; public class ThereIsABugButWhere { private static final VarHandle TEXT; static { try { TEXT = MethodHandles.lookup().findVarHandle(ThereIsABugButWhere.class, "text", String.class); } catch (NoSuchFieldException | IllegalAccessException e) { throw new AssertionError(e); } } private final String text; ThereIsABugButWhere() { text = "FOO"; } public void update(String s) { TEXT.compareAndSet(this, "FOO", s); } public static void main(String[] args) { new ThereIsABugButWhere().update("BAR"); } } --- If you execute it, you get Exception in thread "main" java.lang.UnsupportedOperationException at java.base/java.lang.invoke.VarForm.getMemberName(VarForm.java:99) at java.base/java.lang.invoke.VarHandleGuards.guard_LLL_Z(VarHandleGuards.java:77) at ThereIsABugButWhere.update(ThereIsABugButWhere.java:22) at ThereIsABugButWhere.main(ThereIsABugButWhere.java:26) It takes me 20 mins to find the issue ... I think we can improve the error message or even better report the issue at the right location :) regards, R?mi From darcy at openjdk.java.net Sat Dec 12 18:45:04 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 12 Dec 2020 18:45:04 GMT Subject: [jdk16] RFR: 8258140: Update @jls tags in java.base for renamed/renumbered sections Message-ID: <_RiO7ZyyhNU4SCyfK5fMWIe3LaNGLmazWeQbPsg5XcE=.219cb919-5716-45bf-a915-2e54f4cd8796@github.com> Given upcoming changes in the JLS terminology around the term "type", various sections were renamed: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html The @jls tags in the java.base module which refer to the renamed sections should be updated. Analogous changes in the java.compiler module made under JDK-8258060. ------------- Commit messages: - 8258140 Changes: https://git.openjdk.java.net/jdk16/pull/15/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=15&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258140 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk16/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/15/head:pull/15 PR: https://git.openjdk.java.net/jdk16/pull/15 From jjg at openjdk.java.net Sun Dec 13 00:25:07 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sun, 13 Dec 2020 00:25:07 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search Message-ID: This is for JDK16, as a precursor to fixing JDK-8258002. While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. ------------- Commit messages: - JDK-8247994: Localize javadoc search Changes: https://git.openjdk.java.net/jdk16/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247994 Stats: 122 lines in 9 files changed: 88 ins; 6 del; 28 mod Patch: https://git.openjdk.java.net/jdk16/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk16/pull/16 From jjg at openjdk.java.net Sun Dec 13 00:25:08 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sun, 13 Dec 2020 00:25:08 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. make/CompileInterimLangtools.gmk line 77: > 75: Standard.java, \ > 76: EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \ > 77: COPY := .gif .png .xml .css .js .js.template .txt javax.tools.JavaCompilerTool, \ Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries. (Future RFE?) ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From martin at openjdk.java.net Sun Dec 13 03:36:11 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Sun, 13 Dec 2020 03:36:11 GMT Subject: [jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException Message-ID: 8254350: CompletableFuture.get may swallow InterruptedException ------------- Commit messages: - JDK-8254350 Changes: https://git.openjdk.java.net/jdk16/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254350 Stats: 178 lines in 3 files changed: 170 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/17/head:pull/17 PR: https://git.openjdk.java.net/jdk16/pull/17 From alanb at openjdk.java.net Sun Dec 13 08:31:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 13 Dec 2020 08:31:57 GMT Subject: [jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 03:31:44 GMT, Martin Buchholz wrote: > 8254350: CompletableFuture.get may swallow InterruptedException Previously reviewed for openjdk/jdk, looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/17 From dl at openjdk.java.net Sun Dec 13 11:38:58 2020 From: dl at openjdk.java.net (Doug Lea) Date: Sun, 13 Dec 2020 11:38:58 GMT Subject: [jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 03:31:44 GMT, Martin Buchholz wrote: > 8254350: CompletableFuture.get may swallow InterruptedException Marked as reviewed by dl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/17 From martin at openjdk.java.net Sun Dec 13 19:20:59 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Sun, 13 Dec 2020 19:20:59 GMT Subject: [jdk16] Integrated: 8254350: CompletableFuture.get may swallow InterruptedException In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 03:31:44 GMT, Martin Buchholz wrote: > 8254350: CompletableFuture.get may swallow InterruptedException This pull request has now been integrated. Changeset: 43dc3f79 Author: Martin Buchholz URL: https://git.openjdk.java.net/jdk16/commit/43dc3f79 Stats: 178 lines in 3 files changed: 170 ins; 5 del; 3 mod 8254350: CompletableFuture.get may swallow InterruptedException Reviewed-by: alanb, dl ------------- PR: https://git.openjdk.java.net/jdk16/pull/17 From martin at openjdk.java.net Mon Dec 14 00:40:08 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 14 Dec 2020 00:40:08 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v4] In-Reply-To: References: Message-ID: > 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: JDK-8234131 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1647/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1647&range=03 Stats: 314 lines in 41 files changed: 107 ins; 41 del; 166 mod Patch: https://git.openjdk.java.net/jdk/pull/1647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1647/head:pull/1647 PR: https://git.openjdk.java.net/jdk/pull/1647 From martin at openjdk.java.net Mon Dec 14 00:44:55 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 14 Dec 2020 00:44:55 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3] In-Reply-To: References: Message-ID: <7mGVc2oGVjEtq_YQcmeq1NtnXP8OYNIh94W2hc8xC6E=.4924c0d5-68d1-4073-9b9f-07790c29fb47@github.com> On Fri, 11 Dec 2020 15:07:45 GMT, Petr Jane?ek wrote: >> The changes to doc comments look good. >> >> Thanks for incorporating my earlier code snippet suggestions published on [concurrency-interest](http://cs.oswego.edu/pipermail/concurrency-interest/2020-November/017264.html)! > > This also fixes issue [JDK-8257671](https://bugs.openjdk.java.net/browse/JDK-8257671): _ThreadPoolExecutor.Discard*Policy: rejected tasks are not cancelled_, by updating the `TPE.Discard*Policy` JavaDocs. > > I filed it days before the code went in as I did not see the JavaDoc update in JDK, sorry for my impatience and thank you for the fix. I cannot update the Jira, please link it to this PR, too. @JanecekPetr Thank you very much. I've updated JIRA and this pull request for JDK-8257671 ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From david.holmes at oracle.com Mon Dec 14 02:25:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2020 12:25:52 +1000 Subject: Impossible (?) code path resulting in IllegalStateException on jdk14+ In-Reply-To: References: Message-ID: Hi Dawid, This appears to be a bug in AbstractQueuedSynchronizer and FJP interaction, so cc'ing core-libs as this is not a hotspot issue. Also cc'ing Martin and Doug as this is a j.u.c bug. Cheers, David On 12/12/2020 12:56 am, Dawid Weiss wrote: > So, I know what this is. Sort of. > > This isn't a compiler error (sigh of relief). It's a kind of interplay > between parallel streams (which uses the common ForkJoinPool) and the > queue's blocking operations. > > In our code streams use an op closure which sends items to an > ArrayBlockingQueue. This queue is being drained by a separate thread. > Everything works up until a certain moment when this happens on > queue.put() -- I've modified JDK 16 source code and recompiled it to > see what's happening: > > Suppressed: java.util.concurrent.RejectedExecutionException: Thread > limit exceeded replacing blocked worker > at java.base/java.util.concurrent.ForkJoinPool.tryCompensate(ForkJoinPool.java:1579) > at java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3124) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1614) > at java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:371) > > This exception causes the try-finally block in ArrayBlockingQueue to > hit the finally block unexpectedly (without the attempt to re-acquire > the lock!), eventually leading to the original odd exception I > reported: > > Caused by: java.lang.IllegalMonitorStateException > at java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > at java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > at java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:378) > > This is then propagated up to the caller of queue.put() > > A full simplified repro (without streams) is here: > https://gist.github.com/dweiss/4787b7aa503ef5702e94d73178c3c842 > > When you run it under JDK14+, it'll result in: > > java.lang.IllegalMonitorStateException > at java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > ... > > This code works on JDK11, by the way. What I find a bit > counterintuitive is that the original test (code) doesn't make any > explicit use of ForkJoinPool - it just collects items from a parallel > stream and involves throwing random exceptions from ops on that > stream... This was a bit unexpected. > > Dawid > > > On Thu, Dec 10, 2020 at 5:25 PM Dawid Weiss wrote: >> >> Hello, >> >> I'm scratching my head again over a bug we encountered in randomized >> tests. The code is quite complex so before I start to try to isolate I >> thought I'd ask if it rings a bell for anybody. >> >> The bug is reproducible for certain seeds but happens only after some >> VM warmup - the same test is executed a few dozen times, then the >> problem starts showing up. This only happens on jdk 14 and jdk 15 >> (didn't test on jdk 16 branch). Looks like something related to OSR/ >> compilation races. >> >> In the end, we get this exception: >> >> java.lang.IllegalMonitorStateException >> at java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) >> at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) >> at java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) >> at java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:373) >> [stack omitted] >> >> This doesn't seem possible from Java code alone -- it's this snippet >> in ArrayBlockingQueue: >> >> lock.lockInterruptibly(); >> try { >> while (count == items.length) >> notFull.await(); >> enqueue(e); >> } finally { >> lock.unlock(); // <<< bam... >> } >> >> If the code entered the lock-protected block it should never throw >> IllegalMonitorStateException, right? >> >> I'll start digging in spare moments but hints at how to isolate this/ >> verify what this can be (other than bisecting git repo) would be very >> welcome! >> >> Dawid From martinrb at google.com Mon Dec 14 02:48:14 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 13 Dec 2020 18:48:14 -0800 Subject: Impossible (?) code path resulting in IllegalStateException on jdk14+ In-Reply-To: References: Message-ID: 1. JDK-8258187 IllegalMonitorStateException in ArrayBlockingQueue It's surprising that you can have a repro which is essentially just simple producer-consumer. Can we remove the forkjoinpool from the repro (just threads?) On Sun, Dec 13, 2020 at 6:28 PM David Holmes wrote: > Hi Dawid, > > This appears to be a bug in AbstractQueuedSynchronizer and FJP > interaction, so cc'ing core-libs as this is not a hotspot issue. Also > cc'ing Martin and Doug as this is a j.u.c bug. > > Cheers, > David > > On 12/12/2020 12:56 am, Dawid Weiss wrote: > > So, I know what this is. Sort of. > > > > This isn't a compiler error (sigh of relief). It's a kind of interplay > > between parallel streams (which uses the common ForkJoinPool) and the > > queue's blocking operations. > > > > In our code streams use an op closure which sends items to an > > ArrayBlockingQueue. This queue is being drained by a separate thread. > > Everything works up until a certain moment when this happens on > > queue.put() -- I've modified JDK 16 source code and recompiled it to > > see what's happening: > > > > Suppressed: java.util.concurrent.RejectedExecutionException: Thread > > limit exceeded replacing blocked worker > > at > java.base/java.util.concurrent.ForkJoinPool.tryCompensate(ForkJoinPool.java:1579) > > at > java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3124) > > at > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1614) > > at > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:371) > > > > This exception causes the try-finally block in ArrayBlockingQueue to > > hit the finally block unexpectedly (without the attempt to re-acquire > > the lock!), eventually leading to the original odd exception I > > reported: > > > > Caused by: java.lang.IllegalMonitorStateException > > at > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > at > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > > at > java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > > at > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:378) > > > > This is then propagated up to the caller of queue.put() > > > > A full simplified repro (without streams) is here: > > https://gist.github.com/dweiss/4787b7aa503ef5702e94d73178c3c842 > > > > When you run it under JDK14+, it'll result in: > > > > java.lang.IllegalMonitorStateException > > at > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > ... > > > > This code works on JDK11, by the way. What I find a bit > > counterintuitive is that the original test (code) doesn't make any > > explicit use of ForkJoinPool - it just collects items from a parallel > > stream and involves throwing random exceptions from ops on that > > stream... This was a bit unexpected. > > > > Dawid > > > > > > On Thu, Dec 10, 2020 at 5:25 PM Dawid Weiss > wrote: > >> > >> Hello, > >> > >> I'm scratching my head again over a bug we encountered in randomized > >> tests. The code is quite complex so before I start to try to isolate I > >> thought I'd ask if it rings a bell for anybody. > >> > >> The bug is reproducible for certain seeds but happens only after some > >> VM warmup - the same test is executed a few dozen times, then the > >> problem starts showing up. This only happens on jdk 14 and jdk 15 > >> (didn't test on jdk 16 branch). Looks like something related to OSR/ > >> compilation races. > >> > >> In the end, we get this exception: > >> > >> java.lang.IllegalMonitorStateException > >> at > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > >> at > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > >> at > java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > >> at > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:373) > >> [stack omitted] > >> > >> This doesn't seem possible from Java code alone -- it's this snippet > >> in ArrayBlockingQueue: > >> > >> lock.lockInterruptibly(); > >> try { > >> while (count == items.length) > >> notFull.await(); > >> enqueue(e); > >> } finally { > >> lock.unlock(); // <<< bam... > >> } > >> > >> If the code entered the lock-protected block it should never throw > >> IllegalMonitorStateException, right? > >> > >> I'll start digging in spare moments but hints at how to isolate this/ > >> verify what this can be (other than bisecting git repo) would be very > >> welcome! > >> > >> Dawid > From david.holmes at oracle.com Mon Dec 14 02:57:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2020 12:57:32 +1000 Subject: Impossible (?) code path resulting in IllegalStateException on jdk14+ In-Reply-To: References: Message-ID: <90edebda-fac2-8404-abaf-63a25bb2af61@oracle.com> Hi Martin, On 14/12/2020 12:48 pm, Martin Buchholz wrote: > 1. JDK-8258187 > > > IllegalMonitorStateException in ArrayBlockingQueue > > > > It's surprising that you can have a repro which is essentially just > simple producer-consumer.? Can we remove the forkjoinpool from the repro > (just threads?) AFAICS the FJP is critical here as it is the unexpected exception from managedBlock() that causes the problem. Cheers, David > On Sun, Dec 13, 2020 at 6:28 PM David Holmes > wrote: > > Hi Dawid, > > This appears to be a bug in AbstractQueuedSynchronizer and FJP > interaction, so cc'ing core-libs as this is not a hotspot issue. Also > cc'ing Martin and Doug as this is a j.u.c bug. > > Cheers, > David > > On 12/12/2020 12:56 am, Dawid Weiss wrote: > > So, I know what this is. Sort of. > > > > This isn't a compiler error (sigh of relief). It's a kind of > interplay > > between parallel streams (which uses the common ForkJoinPool) and the > > queue's blocking operations. > > > > In our code streams use an op closure which sends items to an > > ArrayBlockingQueue. This queue is being drained by a separate thread. > > Everything works up until a certain moment when this happens on > > queue.put() -- I've modified JDK 16 source code and recompiled it to > > see what's happening: > > > > Suppressed: java.util.concurrent.RejectedExecutionException: Thread > > limit exceeded replacing blocked worker > > at > java.base/java.util.concurrent.ForkJoinPool.tryCompensate(ForkJoinPool.java:1579) > > at > java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3124) > > at > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1614) > > at > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:371) > > > > This exception causes the try-finally block in ArrayBlockingQueue to > > hit the finally block unexpectedly (without the attempt to re-acquire > > the lock!), eventually leading to the original odd exception I > > reported: > > > > Caused by: java.lang.IllegalMonitorStateException > > at > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > at > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > > at > java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > > at > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:378) > > > > This is then propagated up to the caller of queue.put() > > > > A full simplified repro (without streams) is here: > > https://gist.github.com/dweiss/4787b7aa503ef5702e94d73178c3c842 > > > > > When you run it under JDK14+, it'll result in: > > > > java.lang.IllegalMonitorStateException > >? ? ? ? ? at > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > ... > > > > This code works on JDK11, by the way. What I find a bit > > counterintuitive is that the original test (code) doesn't make any > > explicit use of ForkJoinPool - it just collects items from a parallel > > stream and involves throwing random exceptions from ops on that > > stream... This was a bit unexpected. > > > > Dawid > > > > > > On Thu, Dec 10, 2020 at 5:25 PM Dawid Weiss > > wrote: > >> > >> Hello, > >> > >> I'm scratching my head again over a bug we encountered in randomized > >> tests. The code is quite complex so before I start to try to > isolate I > >> thought I'd ask if it rings a bell for anybody. > >> > >> The bug is reproducible for certain seeds but happens only after > some > >> VM warmup - the same test is executed a few dozen times, then the > >> problem starts showing up. This only happens on jdk 14 and jdk 15 > >> (didn't test on jdk 16 branch). Looks like something related to OSR/ > >> compilation races. > >> > >> In the end, we get this exception: > >> > >> java.lang.IllegalMonitorStateException > >> at > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > >> at > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > >> at > java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > >> at > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:373) > >> [stack omitted] > >> > >> This doesn't seem possible from Java code alone -- it's this snippet > >> in ArrayBlockingQueue: > >> > >> lock.lockInterruptibly(); > >> try { > >>? ? ? while (count == items.length) > >>? ? ? ? ? notFull.await(); > >>? ? ? enqueue(e); > >> } finally { > >>? ? ?lock.unlock();? ? ?// <<< bam... > >> } > >> > >> If the code entered the lock-protected block it should never throw > >> IllegalMonitorStateException, right? > >> > >> I'll start digging in spare moments but hints at how to isolate > this/ > >> verify what this can be (other than bisecting git repo) would be > very > >> welcome! > >> > >> Dawid > From dongbo at openjdk.java.net Mon Dec 14 06:02:02 2020 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 14 Dec 2020 06:02:02 GMT Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions Message-ID: This patch optimizes vectorial rotate (immediate) on aarch64 with shift and insert instructions, i.e. SLI and SRI. Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. Tests under `test/hotspot/jtreg/compiler/c2/cr6340864/` runned specially for the correctness and passed. The JMH micro `test/micro/org/openjdk/bench/java/lang/RotateBenchmark.java` is used for performance test. Witnessed ~15.4% performance improvements on Kunpeng920 (CPU tsv110), but ~15.8% regression on Kunpeng916 (CPU A72). So a switch `UseSIMDShiftInsertForRotation` is introduced on aarch64 with default value `false`, and set `true` for Kunpeng920. The `RotateBenchmark.java` JMH micro-benchmark results on Kunpeng920: Benchmark (SHIFT) (TESTSIZE) Mode Cnt Score Error Units # kunpeng 920, -XX:-UseSIMDShiftInsertForRotation RotateBenchmark.testRotateLeftI 20 1024 thrpt 10 3524.840 ? 2.365 ops/ms RotateBenchmark.testRotateLeftIImm 20 1024 thrpt 10 3961.288 ? 0.897 ops/ms RotateBenchmark.testRotateLeftL 20 1024 thrpt 10 1704.321 ? 11.309 ops/ms RotateBenchmark.testRotateLeftLImm 20 1024 thrpt 10 2137.924 ? 2.215 ops/ms RotateBenchmark.testRotateRightI 20 1024 thrpt 10 3536.960 ? 7.945 ops/ms RotateBenchmark.testRotateRightIImm 20 1024 thrpt 10 3961.552 ? 0.673 ops/ms RotateBenchmark.testRotateRightL 20 1024 thrpt 10 1729.868 ? 0.468 ops/ms RotateBenchmark.testRotateRightLImm 20 1024 thrpt 10 2132.458 ? 3.385 ops/ms # kunpeng 920, default, -XX:+UseSIMDShiftInsertForRotation RotateBenchmark.testRotateLeftI 20 1024 thrpt 10 3504.602 ? 21.609 ops/ms RotateBenchmark.testRotateLeftIImm 20 1024 thrpt 10 4569.820 ? 7.455 ops/ms RotateBenchmark.testRotateLeftL 20 1024 thrpt 10 1730.735 ? 0.701 ops/ms RotateBenchmark.testRotateLeftLImm 20 1024 thrpt 10 2469.796 ? 0.981 ops/ms RotateBenchmark.testRotateRightI 20 1024 thrpt 10 3540.899 ? 7.679 ops/ms RotateBenchmark.testRotateRightIImm 20 1024 thrpt 10 4571.876 ? 0.879 ops/ms RotateBenchmark.testRotateRightL 20 1024 thrpt 10 1731.499 ? 0.877 ops/ms RotateBenchmark.testRotateRightLImm 20 1024 thrpt 10 2469.454 ? 0.705 ops/ms This also moves all logical and shifting NEON instructions from `aarch64.ad` to `aarch64_neon.ad`, and has two minor improvements of supporting vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`. ------------- Commit messages: - 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions Changes: https://git.openjdk.java.net/jdk/pull/1761/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1761&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256820 Stats: 2899 lines in 9 files changed: 1561 ins; 1014 del; 324 mod Patch: https://git.openjdk.java.net/jdk/pull/1761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1761/head:pull/1761 PR: https://git.openjdk.java.net/jdk/pull/1761 From ngasson at openjdk.java.net Mon Dec 14 07:52:17 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 14 Dec 2020 07:52:17 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v3] In-Reply-To: <_xKfCmJj_9WoZWAniJihNjn5YtpLXvYLgexXMLmpzBQ=.9b4e6a37-2ec3-4cc2-91f7-5df49aa06f35@github.com> References: <3a5slI0Zl90wUdV51eoccwUjFaWAx4MVW0uf-P2Uv3Y=.b581e478-928e-40c3-aa5f-6d439b22c94e@github.com> <_xKfCmJj_9WoZWAniJihNjn5YtpLXvYLgexXMLmpzBQ=.9b4e6a37-2ec3-4cc2-91f7-5df49aa06f35@github.com> Message-ID: On Fri, 11 Dec 2020 09:29:57 GMT, Andrew Haley wrote: >> Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Separate RegSet and FloatRegSet >> - Merge branch 'master' into 8257882 >> - Review comments >> - 8257882: Implement linkToNative intrinsic on AArch64 >> >> This is more-or-less a straight port of the x86 code to AArch64. >> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() >> to generate a blob that jumps to the native function entry point. This >> simply switches the thread state from Java to native and handles the >> safepoint poll on return from native code. >> >> AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame >> pointer) may hold a live oop over the MachCallNative node. Normally this >> would be saved by RegisterSaver::save_live_registers() but the native >> invoker blob is not a "proper" stub routine so doesn't have an oop map. >> I copied the x86 solution to this where the frame pointer register is >> saved to the stack and a pointer to that is stored in the frame anchor. >> This is then read back and added to the register map when walking the >> stack. I saw in the PR comments [1] that this might be a temporary fix, >> but I'm not sure if there's any plan to change that now? >> >> Another potential fix might be to change the C2 register definition of >> R29 and R29_H to be save-on-call as below. This works for the >> TestStackWalk.java test case but I don't know whether it has other >> unintended side-effects. >> >> reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp >> reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); >> >> JMH results from jdk/incubator/foreign/CallOverhead.java to show it's >> working: >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op >> CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op >> CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op >> CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op >> CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op >> CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op >> CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op >> CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op >> CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op >> CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op >> CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op >> CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op >> CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op >> CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op >> CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op >> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op >> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op >> >> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3159: > >> 3157: >> 3158: __ safepoint_poll(L_safepoint_poll_slow_path, rthread, true /* at_return */, false /* in_nmethod */); >> 3159: > > This looks wrong: please look at the definition of MacroAssembler::safepoint_poll, which has an acquire flag. Yes this is bad: it generates the correct code but the arguments are totally wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From ngasson at openjdk.java.net Mon Dec 14 07:52:14 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 14 Dec 2020 07:52:14 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v4] In-Reply-To: References: Message-ID: > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Release-store to thread state and fix safepoint_poll args ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1711/files - new: https://git.openjdk.java.net/jdk/pull/1711/files/d7915ff7..289f4270 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1711&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1711/head:pull/1711 PR: https://git.openjdk.java.net/jdk/pull/1711 From dawid.weiss at gmail.com Mon Dec 14 09:28:30 2020 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 14 Dec 2020 10:28:30 +0100 Subject: Impossible (?) code path resulting in IllegalStateException on jdk14+ In-Reply-To: <90edebda-fac2-8404-abaf-63a25bb2af61@oracle.com> References: <90edebda-fac2-8404-abaf-63a25bb2af61@oracle.com> Message-ID: Hello David, Martin, Doug, > AFAICS the FJP is critical here as it is the unexpected exception from managedBlock() that causes the problem. Correct. Also, something has changed in the behavior of streams in JDK14 that I haven't tracked down that causes the "size" of the FJ pool to grow until it explodes. The example I provided is distilled from a (much) more complex scenario where the underlying queue was concurrently (and repeatedly) drained and cleared, yet the "size" (as reported by toString() - not the active thread set) of the fj pool still gradually increased and eventually resulted in the (masked) RejectedExecutionException. I looked at the code in FJ pool briefly but didn't dive deep - it's super interesting to read but also heavily optimized and complex... I admit we might have made a mistake of switching to parallel streams as potentially blocking producers... But this doesn't change the fact that the exception you can get from ArrayBlockingQueue is quite unexpected so perhaps it's worth looking into. Dawid On Mon, Dec 14, 2020 at 3:57 AM David Holmes wrote: > > Hi Martin, > > On 14/12/2020 12:48 pm, Martin Buchholz wrote: > > 1. JDK-8258187 > > > > > > IllegalMonitorStateException in ArrayBlockingQueue > > > > > > > > It's surprising that you can have a repro which is essentially just > > simple producer-consumer. Can we remove the forkjoinpool from the repro > > (just threads?) > > AFAICS the FJP is critical here as it is the unexpected exception from > managedBlock() that causes the problem. > > Cheers, > David > > > On Sun, Dec 13, 2020 at 6:28 PM David Holmes > > wrote: > > > > Hi Dawid, > > > > This appears to be a bug in AbstractQueuedSynchronizer and FJP > > interaction, so cc'ing core-libs as this is not a hotspot issue. Also > > cc'ing Martin and Doug as this is a j.u.c bug. > > > > Cheers, > > David > > > > On 12/12/2020 12:56 am, Dawid Weiss wrote: > > > So, I know what this is. Sort of. > > > > > > This isn't a compiler error (sigh of relief). It's a kind of > > interplay > > > between parallel streams (which uses the common ForkJoinPool) and the > > > queue's blocking operations. > > > > > > In our code streams use an op closure which sends items to an > > > ArrayBlockingQueue. This queue is being drained by a separate thread. > > > Everything works up until a certain moment when this happens on > > > queue.put() -- I've modified JDK 16 source code and recompiled it to > > > see what's happening: > > > > > > Suppressed: java.util.concurrent.RejectedExecutionException: Thread > > > limit exceeded replacing blocked worker > > > at > > java.base/java.util.concurrent.ForkJoinPool.tryCompensate(ForkJoinPool.java:1579) > > > at > > java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3124) > > > at > > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1614) > > > at > > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:371) > > > > > > This exception causes the try-finally block in ArrayBlockingQueue to > > > hit the finally block unexpectedly (without the attempt to re-acquire > > > the lock!), eventually leading to the original odd exception I > > > reported: > > > > > > Caused by: java.lang.IllegalMonitorStateException > > > at > > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > > at > > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > > > at > > java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > > > at > > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:378) > > > > > > This is then propagated up to the caller of queue.put() > > > > > > A full simplified repro (without streams) is here: > > > https://gist.github.com/dweiss/4787b7aa503ef5702e94d73178c3c842 > > > > > > > > When you run it under JDK14+, it'll result in: > > > > > > java.lang.IllegalMonitorStateException > > > at > > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > > ... > > > > > > This code works on JDK11, by the way. What I find a bit > > > counterintuitive is that the original test (code) doesn't make any > > > explicit use of ForkJoinPool - it just collects items from a parallel > > > stream and involves throwing random exceptions from ops on that > > > stream... This was a bit unexpected. > > > > > > Dawid > > > > > > > > > On Thu, Dec 10, 2020 at 5:25 PM Dawid Weiss > > > wrote: > > >> > > >> Hello, > > >> > > >> I'm scratching my head again over a bug we encountered in randomized > > >> tests. The code is quite complex so before I start to try to > > isolate I > > >> thought I'd ask if it rings a bell for anybody. > > >> > > >> The bug is reproducible for certain seeds but happens only after > > some > > >> VM warmup - the same test is executed a few dozen times, then the > > >> problem starts showing up. This only happens on jdk 14 and jdk 15 > > >> (didn't test on jdk 16 branch). Looks like something related to OSR/ > > >> compilation races. > > >> > > >> In the end, we get this exception: > > >> > > >> java.lang.IllegalMonitorStateException > > >> at > > java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) > > >> at > > java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006) > > >> at > > java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) > > >> at > > java.base/java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:373) > > >> [stack omitted] > > >> > > >> This doesn't seem possible from Java code alone -- it's this snippet > > >> in ArrayBlockingQueue: > > >> > > >> lock.lockInterruptibly(); > > >> try { > > >> while (count == items.length) > > >> notFull.await(); > > >> enqueue(e); > > >> } finally { > > >> lock.unlock(); // <<< bam... > > >> } > > >> > > >> If the code entered the lock-protected block it should never throw > > >> IllegalMonitorStateException, right? > > >> > > >> I'll start digging in spare moments but hints at how to isolate > > this/ > > >> verify what this can be (other than bisecting git repo) would be > > very > > >> welcome! > > >> > > >> Dawid > > From hannesw at openjdk.java.net Mon Dec 14 09:52:59 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 14 Dec 2020 09:52:59 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. Looks good in general. `` shouldn't be localized as it is an internal tag (see inline comment). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40: > 38: var MIN_RESULTS = 3; > 39: var MAX_RESULTS = 500; > 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##"; `` is not a string that is ever shown to the user, it is what is used by javadoc to denote the default package (see `toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't be localized as that would break behaviour for code in the default package (and show the localized string as package name, instead of no package name). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java line 256: > 254: sb.append(resources.getText(m.group("key"))); > 255: } catch (MissingResourceException e) { > 256: sb.append(m.group()); Shouldn't we propagate an error here, or issue a warning? If a key is missing localized properties the value from default properties should be used, so this should never happen, right? ------------- Changes requested by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/16 From hannesw at openjdk.java.net Mon Dec 14 09:58:56 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 14 Dec 2020 09:58:56 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 09:34:31 GMT, Hannes Walln?fer wrote: >> This is for JDK16, as a precursor to fixing JDK-8258002. >> >> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. >> >> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java line 256: > >> 254: sb.append(resources.getText(m.group("key"))); >> 255: } catch (MissingResourceException e) { >> 256: sb.append(m.group()); > > Shouldn't we propagate an error here, or issue a warning? If a key is missing localized properties the value from default properties should be used, so this should never happen, right? I see the added check for "##REPLACE:" in TestSearch.java will catch that case, so I guess it's ok. ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From sgehwolf at openjdk.java.net Mon Dec 14 12:50:19 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Dec 2020 12:50:19 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v2] In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: > This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1393/files - new: https://git.openjdk.java.net/jdk/pull/1393/files/1832b70f..fd55ffd7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=00-01 Stats: 142480 lines in 1880 files changed: 116851 ins; 13097 del; 12532 mod Patch: https://git.openjdk.java.net/jdk/pull/1393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393 PR: https://git.openjdk.java.net/jdk/pull/1393 From mcimadamore at openjdk.java.net Mon Dec 14 14:51:07 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Dec 2020 14:51:07 GMT Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory segments of different kinds are used Message-ID: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). Here are some numbers before the patch: Benchmark Mode Cnt Score Error Units LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: Benchmark Mode Cnt Score Error Units LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! ------------- Commit messages: - * Add argument type profiling to MemoryAccess Changes: https://git.openjdk.java.net/jdk16/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=19&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258242 Stats: 224 lines in 8 files changed: 215 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk16/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/19/head:pull/19 PR: https://git.openjdk.java.net/jdk16/pull/19 From vlivanov at openjdk.java.net Mon Dec 14 15:43:56 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 14 Dec 2020 15:43:56 GMT Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory segments of different kinds are used In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> Message-ID: On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore wrote: > This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. > > In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. > > To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). > > Here are some numbers before the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op > > As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op > > That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/19 From redestad at openjdk.java.net Mon Dec 14 15:51:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Dec 2020 15:51:00 GMT Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory segments of different kinds are used In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> Message-ID: <34cCfmLZjUH77gP1Hk0Fd-KT2vqZ5Ox1W08qeMmgjlM=.4e226bce-7f59-41dd-a64f-91be94568514@github.com> On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore wrote: > This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. > > In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. > > To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). > > Here are some numbers before the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op > > As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op > > That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! src/java.base/share/classes/jdk/internal/access/foreign/MemorySegmentProxy.java line 32: > 30: > 31: /** > 32: * This proxy interface is required to allow instances of the {@code MemorySegment} interface (which is defined inside "This abstract base class.."? I don't mind the current name, but should the class be renamed `AbstractMemorySegmentProxy`? ------------- PR: https://git.openjdk.java.net/jdk16/pull/19 From mcimadamore at openjdk.java.net Mon Dec 14 17:17:00 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Dec 2020 17:17:00 GMT Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory segments of different kinds are used In-Reply-To: <34cCfmLZjUH77gP1Hk0Fd-KT2vqZ5Ox1W08qeMmgjlM=.4e226bce-7f59-41dd-a64f-91be94568514@github.com> References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> <34cCfmLZjUH77gP1Hk0Fd-KT2vqZ5Ox1W08qeMmgjlM=.4e226bce-7f59-41dd-a64f-91be94568514@github.com> Message-ID: On Mon, 14 Dec 2020 15:48:07 GMT, Claes Redestad wrote: >> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. >> >> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. >> >> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). >> >> Here are some numbers before the patch: >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op >> LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op >> LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op >> LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op >> >> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op >> LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op >> >> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! > > src/java.base/share/classes/jdk/internal/access/foreign/MemorySegmentProxy.java line 32: > >> 30: >> 31: /** >> 32: * This proxy interface is required to allow instances of the {@code MemorySegment} interface (which is defined inside > > "This abstract base class.."? > > I don't mind the current name, but should the class be renamed `AbstractMemorySegmentProxy`? I'll fix the doc - since this is a transitional artifact (will disappear when API is finalized an in java.base) I'd prefer to avoid the renaming ------------- PR: https://git.openjdk.java.net/jdk16/pull/19 From mcimadamore at openjdk.java.net Mon Dec 14 18:07:14 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Dec 2020 18:07:14 GMT Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory segments of different kinds are used [v2] In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> Message-ID: > This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. > > In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. > > To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). > > Here are some numbers before the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op > > As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op > > That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/19/files - new: https://git.openjdk.java.net/jdk16/pull/19/files/324d5b92..81472e6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=19&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=19&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/19/head:pull/19 PR: https://git.openjdk.java.net/jdk16/pull/19 From redestad at openjdk.java.net Mon Dec 14 18:14:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Dec 2020 18:14:00 GMT Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory segments of different kinds are used [v2] In-Reply-To: References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> Message-ID: On Mon, 14 Dec 2020 18:07:14 GMT, Maurizio Cimadamore wrote: >> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. >> >> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. >> >> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). >> >> Here are some numbers before the patch: >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op >> LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op >> LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op >> LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op >> >> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op >> LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op >> >> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix javadoc Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/19 From rriggs at openjdk.java.net Mon Dec 14 19:39:57 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Dec 2020 19:39:57 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 18:51:10 GMT, Richard Fussenegger wrote: > 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant The `version` method is described in the javadoc as only being applicable to variant = 2 UUIDs. Changing the behavior to throw a `UnsupportedOperationException` is not a compatible change. There is very little value in adding the exception doing so might prevent existing applications from continuing to function. Repeating the limitation to version 2 to the javadoc of the version method as far as this request can go. Otherwise, please close the PR without integrating. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1467 From asemenyuk at openjdk.java.net Mon Dec 14 19:40:38 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 14 Dec 2020 19:40:38 GMT Subject: RFR: 8255899: Allow uninstallation of jpackage exe bundles Message-ID: Adds support for "uninstall" parameter for exe uninstallers created by jpackage. Added logging and error reporting to exe uninstallers. - jpackage jni lib (jpackage.cpp): added functionality to extract ProductCode property from msi file before the file is embedded in exe installer. Extracted value of ProductCode property is saved as another resource entry in exe installer. Value of this property is needed for uninstall. - exe installer (MsiWrapper.cpp): added functionality to extract value of ProductCode from the resources and use it to uninstall the product. The code is not invoking msiexec.exe, but uses MSI API directly. Besides improved logging and error reporting. Previously it didn't exist at all, nothing was written to console/message box displayed in case of any errors. ------------- Commit messages: - 8255899: Allow uninstallation of jpackage exe bundles - 8255899: Allow uninstallation of jpackage exe bundles Changes: https://git.openjdk.java.net/jdk/pull/1770/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1770&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255899 Stats: 2522 lines in 27 files changed: 2147 ins; 354 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1770.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1770/head:pull/1770 PR: https://git.openjdk.java.net/jdk/pull/1770 From bchristi at openjdk.java.net Mon Dec 14 19:41:05 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 14 Dec 2020 19:41:05 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh Message-ID: This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). Here are the changes covering core libraries code and tests. Terms were changed as follows: 1. grandfathered -> legacy 2. blacklist -> filter or reject 3. whitelist -> allow or accept 4. master -> coordinator 5. slave -> worker Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. ------------- Commit messages: - Terminology Cleanup - corelibs terminology refresh - bchristi Changes: https://git.openjdk.java.net/jdk/pull/1771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253497 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From dfuchs at openjdk.java.net Mon Dec 14 19:47:59 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 14 Dec 2020 19:47:59 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v4] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 21:23:12 GMT, Mahendra Chhipa wrote: >> jaxp.library.SimpleHttpServer >> https://bugs.openjdk.java.net/browse/JDK-8212035 > > Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035 > - Implemnted the review comments. Changes requested by dfuchs (Reviewer). test/lib/jdk/test/lib/net/SimpleHttpServer.java line 105: > 103: Path fPath; > 104: try { > 105: fPath = Paths.get(docRoot, path); Hi Mahendra, I am not comfortable with this. You cannot just concatenate a file system path with a URI path in the general case (think windows file system). I would suggest to transform docRoot into a root URI using `Path.of(docRoot).toURI().normalize()` - then you can probably concatenate the string representation of this root URI with the *raw path* extracted from the request URI, normalize that again (to remove potential double slashes) and convert that back into a Path using Path.of(URI). Some additional conditions might need to be asserted: - `t.getRequestURI().getRawPath()` should either be empty or start with `"/"` (and even that may be a bit lax) - the resulting URI you obtain (after normalization and before converting back to Path) should either be equal to the root URI or start with the root URI. `(rootURI.toString().equals(uri.toString()) || uri.toString().startsWith(rootUri.toString() + "/") )` best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From Roger.Riggs at oracle.com Mon Dec 14 20:15:40 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 14 Dec 2020 15:15:40 -0500 Subject: UUID improvements for discussion Message-ID: Hi, A couple of PRs have been proposed to enhance the java.util.UUID API [3]. PR 1465 proposes a new API to create a UUID from a byte array.? [1] Currently, the caller can convert the byte array to two longs and invoke the existing constructor. The implementation has substantially the same method. PR 1444 works to address the long standing dissatisfaction with creating a UUID from its string form. The current java.util.fromString(string) method accepts input that does not conform to RFC 1422. Changing the method to reject invalid input would not be a compatible change and has been rejected as a solution several times.? This PR proposes to create a new `valueOf` method that accepts only valid input and to deprecate the existing `fromString` method. Though it would be deprecated, the deprecation would serve as a warning to new and upgraded applications. Due to compatibility concerns it is very unlikely that the method could be removed, perhaps ever. The performance of creating a UUID would be the same with either method, the existing fromString method has been optimized. Thoughts? Thanks, Roger [1] https://git.openjdk.java.net/jdk/pull/1465 [2] https://github.com/openjdk/jdk/pull/1444 [3] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/UUID.html From rriggs at openjdk.java.net Mon Dec 14 20:20:56 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Dec 2020 20:20:56 GMT Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput In-Reply-To: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com> References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com> Message-ID: On Thu, 26 Nov 2020 18:24:22 GMT, Richard Fussenegger wrote: > Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. > > Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request. Requested feedback on the API addition/modifications: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072530.html ------------- PR: https://git.openjdk.java.net/jdk/pull/1465 From naoto at openjdk.java.net Mon Dec 14 20:29:56 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Dec 2020 20:29:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: <6mGHyzJFxdntyaLG6CFPBw87a3I7caQuhWGz8hpLneY=.44f01fb2-a150-42e6-a3b0-853d72d24a1b@github.com> On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Looks good to me. test/jdk/java/lang/ClassLoader/Assert.java line 65: > 63: > 64: int switchSource = 0; > 65: if (args.length == 0) { // This is the coordinator version Extra space between "is" and "the." ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1771 From kcr at openjdk.java.net Mon Dec 14 20:38:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Dec 2020 20:38:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From joehw at openjdk.java.net Mon Dec 14 21:15:58 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 14 Dec 2020 21:15:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by joehw (Reviewer). src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135: > 133: * The pattern must be in same format as used in > 134: * {@link java.io.ObjectInputFilter.Config#createFilter}. > 135: * It may define an accept-list of permitted classes, a reject-list of should accept-list be allow-list to be consistent with the other two RMI classes and ObjectInputFilter.Status#ALLOWED? src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: > 150: *

> 151: * Care must be taken when defining such a filter, as defining > 152: * an accept-list too restrictive or a too-wide reject-list may would "an allow-list too restrictive or a reject-list too wide" read better? ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From rriggs at openjdk.java.net Mon Dec 14 21:15:56 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Dec 2020 21:15:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by rriggs (Reviewer). src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135: > 133: * The pattern must be in same format as used in > 134: * {@link java.io.ObjectInputFilter.Config#createFilter}. > 135: * It may define an accept-list of permitted classes, a reject-list of accept -> allow for consistency src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: > 150: *

> 151: * Care must be taken when defining such a filter, as defining > 152: * an accept-list too restrictive or a too-wide reject-list may accept -> allow for consistency ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From mandy.chung at oracle.com Mon Dec 14 21:41:23 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Dec 2020 13:41:23 -0800 Subject: It's not a bug but it's not user friendly In-Reply-To: <950404544.1998857.1607789252808.JavaMail.zimbra@u-pem.fr> References: <950404544.1998857.1607789252808.JavaMail.zimbra@u-pem.fr> Message-ID: I think https://bugs.openjdk.java.net/browse/JDK-8199149 is the relevant RFE. Mandy On 12/12/20 8:07 AM, Remi Forax wrote: > A student of mine send me a code that can be reduced to this code > > --- > import java.lang.invoke.MethodHandles; > import java.lang.invoke.VarHandle; > > public class ThereIsABugButWhere { > private static final VarHandle TEXT; > static { > try { > TEXT = MethodHandles.lookup().findVarHandle(ThereIsABugButWhere.class, "text", String.class); > } catch (NoSuchFieldException | IllegalAccessException e) { > throw new AssertionError(e); > } > } > > > private final String text; > > ThereIsABugButWhere() { > text = "FOO"; > } > > public void update(String s) { > TEXT.compareAndSet(this, "FOO", s); > } > > public static void main(String[] args) { > new ThereIsABugButWhere().update("BAR"); > } > } > > --- > If you execute it, you get > Exception in thread "main" java.lang.UnsupportedOperationException > at java.base/java.lang.invoke.VarForm.getMemberName(VarForm.java:99) > at java.base/java.lang.invoke.VarHandleGuards.guard_LLL_Z(VarHandleGuards.java:77) > at ThereIsABugButWhere.update(ThereIsABugButWhere.java:22) > at ThereIsABugButWhere.main(ThereIsABugButWhere.java:26) > > It takes me 20 mins to find the issue ... > I think we can improve the error message or even better report the issue at the right location :) > > regards, > R?mi From forax at univ-mlv.fr Mon Dec 14 22:01:22 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 14 Dec 2020 23:01:22 +0100 (CET) Subject: It's not a bug but it's not user friendly In-Reply-To: References: <950404544.1998857.1607789252808.JavaMail.zimbra@u-pem.fr> Message-ID: <477528972.838366.1607983282772.JavaMail.zimbra@u-pem.fr> > De: "mandy chung" > ?: "Remi Forax" , "core-libs-dev" > > Envoy?: Lundi 14 D?cembre 2020 22:41:23 > Objet: Re: It's not a bug but it's not user friendly > I think [ https://bugs.openjdk.java.net/browse/JDK-8199149 | > https://bugs.openjdk.java.net/browse/JDK-8199149 ] is the relevant RFE. > Mandy Yes, thanks. R?mi > On 12/12/20 8:07 AM, Remi Forax wrote: >> A student of mine send me a code that can be reduced to this code >> --- >> import java.lang.invoke.MethodHandles; >> import java.lang.invoke.VarHandle; >> public class ThereIsABugButWhere { >> private static final VarHandle TEXT; >> static { >> try { >> TEXT = MethodHandles.lookup().findVarHandle(ThereIsABugButWhere.class, "text", >> String.class); >> } catch (NoSuchFieldException | IllegalAccessException e) { >> throw new AssertionError(e); >> } >> } >> private final String text; >> ThereIsABugButWhere() { >> text = "FOO"; >> } >> public void update(String s) { >> TEXT.compareAndSet(this, "FOO", s); >> } >> public static void main(String[] args) { >> new ThereIsABugButWhere().update("BAR"); >> } >> } >> --- >> If you execute it, you get >> Exception in thread "main" java.lang.UnsupportedOperationException >> at java.base/java.lang.invoke.VarForm.getMemberName(VarForm.java:99) >> at >> java.base/java.lang.invoke.VarHandleGuards.guard_LLL_Z(VarHandleGuards.java:77) >> at ThereIsABugButWhere.update(ThereIsABugButWhere.java:22) >> at ThereIsABugButWhere.main(ThereIsABugButWhere.java:26) >> It takes me 20 mins to find the issue ... >> I think we can improve the error message or even better report the issue at the >> right location :) >> regards, >> R?mi From almatvee at openjdk.java.net Tue Dec 15 00:22:56 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 15 Dec 2020 00:22:56 GMT Subject: RFR: 8255899: Allow uninstallation of jpackage exe bundles In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:33:44 GMT, Alexey Semenyuk wrote: > Adds support for "uninstall" parameter for exe uninstallers created by jpackage. > Added logging and error reporting to exe uninstallers. > > - jpackage jni lib (jpackage.cpp): added functionality to extract ProductCode property from msi file before the file is embedded in exe installer. Extracted value of ProductCode property is saved as another resource entry in exe installer. Value of this property is needed for uninstall. > - exe installer (MsiWrapper.cpp): added functionality to extract value of ProductCode from the resources and use it to uninstall the product. The code is not invoking msiexec.exe, but uses MSI API directly. Besides improved logging and error reporting. Previously it didn't exist at all, nothing was written to console/message box displayed in case of any errors. Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1770 From bchristi at openjdk.java.net Tue Dec 15 01:38:59 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 01:38:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh In-Reply-To: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: > >> 150: *

>> 151: * Care must be taken when defining such a filter, as defining >> 152: * an accept-list too restrictive or a too-wide reject-list may > > would "an allow-list too restrictive or a reject-list too wide" read better? I agree that there is room for improvement here. How about: "...an allow-list too restrictively, or a reject-list too broadly, may..." ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 01:46:08 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 01:46:08 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: updates, per code review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/4efa5d43..29525f05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From joehw at openjdk.java.net Tue Dec 15 01:46:09 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Dec 2020 01:46:09 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian wrote: >> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: >> >>> 150: *

>>> 151: * Care must be taken when defining such a filter, as defining >>> 152: * an accept-list too restrictive or a too-wide reject-list may >> >> would "an allow-list too restrictive or a reject-list too wide" read better? > > I agree that there is room for improvement here. How about: > "...an allow-list too restrictively, or a reject-list too broadly, may..." > ? That sounds good to me ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From jwilhelm at openjdk.java.net Tue Dec 15 03:43:15 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Dec 2020 03:43:15 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <2Yx43vz64GrneweTv0nw17cuOAEzWPovF7LZ8AkDsME=.932a0aa9-2c4b-4949-bb66-c059f3942091@github.com> References: <2Yx43vz64GrneweTv0nw17cuOAEzWPovF7LZ8AkDsME=.932a0aa9-2c4b-4949-bb66-c059f3942091@github.com> Message-ID: On Tue, 15 Dec 2020 03:37:23 GMT, Jesper Wilhelmsson wrote: > Merge change from JDK 16 This pull request has now been integrated. Changeset: 381021ae Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/381021ae Stats: 875 lines in 42 files changed: 644 ins; 154 del; 77 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1775 From jwilhelm at openjdk.java.net Tue Dec 15 03:43:14 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Dec 2020 03:43:14 GMT Subject: Integrated: Merge jdk16 Message-ID: <2Yx43vz64GrneweTv0nw17cuOAEzWPovF7LZ8AkDsME=.932a0aa9-2c4b-4949-bb66-c059f3942091@github.com> Merge change from JDK 16 ------------- Commit messages: - Merge - 8258094: AIX build fails after 8257602 - 8258092: Link to early access platform documentation in TestHtmlTableTags.java - 8254350: CompletableFuture.get may swallow InterruptedException - 8258111: Problemlist compiler/blackhole tests for -Xcomp until JDK-8258101 is fixed - 8257596: Clarify trusted final fields for record classes - 8257919: [JVMCI] profiling info didn't change after reprofile - 8257598: Clarify what component values are used in Record::equals - 8258060: Update @jls tags for renamed/renumbered sections - 8256641: CDS VM operations do not lock the heap - ... and 3 more: https://git.openjdk.java.net/jdk/compare/2c3ae19a...b0ad1bcd The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1775&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1775&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1775/files Stats: 875 lines in 42 files changed: 644 ins; 154 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1775/head:pull/1775 PR: https://git.openjdk.java.net/jdk/pull/1775 From alanb at openjdk.java.net Tue Dec 15 07:36:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Dec 2020 07:36:57 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > updates, per code review test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45: > 43: SocketChannel client = SocketChannel.open (); > 44: client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port)); > 45: SocketChannel channel = server.accept (); Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From ihse at openjdk.java.net Tue Dec 15 09:19:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 09:19:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang wrote: >> I agree that there is room for improvement here. How about: >> "...an allow-list too restrictively, or a reject-list too broadly, may..." >> ? > > Your call, I'm not a native English speaker :-) It felt to me it's 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a restrictive allow-list. It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From ihse at openjdk.java.net Tue Dec 15 09:27:59 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 09:27:59 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 00:22:04 GMT, Jonathan Gibbons wrote: >> This is for JDK16, as a precursor to fixing JDK-8258002. >> >> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. >> >> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. > > make/CompileInterimLangtools.gmk line 77: > >> 75: Standard.java, \ >> 76: EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \ >> 77: COPY := .gif .png .xml .css .js .js.template .txt javax.tools.JavaCompilerTool, \ > > Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries. > (Future RFE?) I agree. The entire design of CompileJavaModules.gmk needs to be updated. I've been procrastinating on cleaning this up, maybe it's time to get going on it... ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From ihse at openjdk.java.net Tue Dec 15 09:27:57 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 09:27:57 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/16 From sgehwolf at openjdk.java.net Tue Dec 15 13:00:00 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 15 Dec 2020 13:00:00 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Mon, 23 Nov 2020 19:58:20 GMT, Severin Gehwolf wrote: >>> With respect to JDK-8255908, the changes look good to me. >> >> Thanks! > > @bobvandette Please review when you've got some cycles to spare. Much appreciated! Ping? Anyone? ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From mcimadamore at openjdk.java.net Tue Dec 15 13:54:03 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Dec 2020 13:54:03 GMT Subject: [jdk16] Integrated: 8258242: Type profile pollution occurs when memory segments of different kinds are used In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com> Message-ID: On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore wrote: > This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method. > > In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation. > > To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`). > > Here are some numbers before the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 11.535 ? 0.039 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 10.860 ? 0.162 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 11.479 ? 0.202 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 10.562 ? 0.027 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.240 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 11.603 ? 0.154 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 10.613 ? 0.128 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.243 ? 0.003 ms/op > > As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch: > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.244 ? 0.002 ms/op > LoopOverPollutedSegments.heap_segment_floats_static avgt 30 0.301 ? 0.001 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.245 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_static avgt 30 0.302 ? 0.004 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.246 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_static avgt 30 0.295 ? 0.006 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.245 ? 0.003 ms/op > > That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help! This pull request has now been integrated. Changeset: 7ff9c856 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk16/commit/7ff9c856 Stats: 225 lines in 8 files changed: 215 ins; 0 del; 10 mod 8258242: Type profile pollution occurs when memory segments of different kinds are used Reviewed-by: vlivanov, redestad ------------- PR: https://git.openjdk.java.net/jdk16/pull/19 From herrick at openjdk.java.net Tue Dec 15 15:07:01 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 15 Dec 2020 15:07:01 GMT Subject: RFR: 8255899: Allow uninstallation of jpackage exe bundles In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:33:44 GMT, Alexey Semenyuk wrote: > Adds support for "uninstall" parameter for exe uninstallers created by jpackage. > Added logging and error reporting to exe uninstallers. > > - jpackage jni lib (jpackage.cpp): added functionality to extract ProductCode property from msi file before the file is embedded in exe installer. Extracted value of ProductCode property is saved as another resource entry in exe installer. Value of this property is needed for uninstall. > - exe installer (MsiWrapper.cpp): added functionality to extract value of ProductCode from the resources and use it to uninstall the product. The code is not invoking msiexec.exe, but uses MSI API directly. Besides improved logging and error reporting. Previously it didn't exist at all, nothing was written to console/message box displayed in case of any errors. Looks fine - passes some additional tests - OK for 17 ------------- Marked as reviewed by herrick (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1770 From psandoz at openjdk.java.net Tue Dec 15 16:14:56 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 15 Dec 2020 16:14:56 GMT Subject: [jdk16] RFR: 8258140: Update @jls tags in java.base for renamed/renumbered sections In-Reply-To: <_RiO7ZyyhNU4SCyfK5fMWIe3LaNGLmazWeQbPsg5XcE=.219cb919-5716-45bf-a915-2e54f4cd8796@github.com> References: <_RiO7ZyyhNU4SCyfK5fMWIe3LaNGLmazWeQbPsg5XcE=.219cb919-5716-45bf-a915-2e54f4cd8796@github.com> Message-ID: On Sat, 12 Dec 2020 18:40:16 GMT, Joe Darcy wrote: > Given upcoming changes in the JLS terminology around the term "type", various sections were renamed: > > https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > The @jls tags in the java.base module which refer to the renamed sections should be updated. > Analogous changes in the java.compiler module made under JDK-8258060. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/15 From asemenyuk at openjdk.java.net Tue Dec 15 16:45:56 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 15 Dec 2020 16:45:56 GMT Subject: Integrated: 8255899: Allow uninstallation of jpackage exe bundles In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:33:44 GMT, Alexey Semenyuk wrote: > Adds support for "uninstall" parameter for exe uninstallers created by jpackage. > Added logging and error reporting to exe uninstallers. > > - jpackage jni lib (jpackage.cpp): added functionality to extract ProductCode property from msi file before the file is embedded in exe installer. Extracted value of ProductCode property is saved as another resource entry in exe installer. Value of this property is needed for uninstall. > - exe installer (MsiWrapper.cpp): added functionality to extract value of ProductCode from the resources and use it to uninstall the product. The code is not invoking msiexec.exe, but uses MSI API directly. Besides improved logging and error reporting. Previously it didn't exist at all, nothing was written to console/message box displayed in case of any errors. This pull request has now been integrated. Changeset: d53ee621 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/d53ee621 Stats: 2522 lines in 27 files changed: 2147 ins; 354 del; 21 mod 8255899: Allow uninstallation of jpackage exe bundles Reviewed-by: almatvee, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/1770 From darcy at openjdk.java.net Tue Dec 15 16:52:08 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Dec 2020 16:52:08 GMT Subject: [jdk16] Integrated: 8258140: Update @jls tags in java.base for renamed/renumbered sections In-Reply-To: <_RiO7ZyyhNU4SCyfK5fMWIe3LaNGLmazWeQbPsg5XcE=.219cb919-5716-45bf-a915-2e54f4cd8796@github.com> References: <_RiO7ZyyhNU4SCyfK5fMWIe3LaNGLmazWeQbPsg5XcE=.219cb919-5716-45bf-a915-2e54f4cd8796@github.com> Message-ID: On Sat, 12 Dec 2020 18:40:16 GMT, Joe Darcy wrote: > Given upcoming changes in the JLS terminology around the term "type", various sections were renamed: > > https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > The @jls tags in the java.base module which refer to the renamed sections should be updated. > Analogous changes in the java.compiler module made under JDK-8258060. This pull request has now been integrated. Changeset: e9113517 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk16/commit/e9113517 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod 8258140: Update @jls tags in java.base for renamed/renumbered sections Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk16/pull/15 From coleenp at openjdk.java.net Tue Dec 15 17:32:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 17:32:03 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Message-ID: See bug for details. Tested: $ java -XX:+StressLdcRewrite -version Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. Error: The unlock option must precede 'StressLdcRewrite'. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version openjdk version "16-internal" 2021-03-16 OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. ------------- Commit messages: - 8257726: Make -XX:+StressLdcRewrite option a diagnostic option - 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Changes: https://git.openjdk.java.net/jdk/pull/1783/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1783&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257726 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1783/head:pull/1783 PR: https://git.openjdk.java.net/jdk/pull/1783 From mayankbansal933 at gmail.com Tue Dec 15 17:47:22 2020 From: mayankbansal933 at gmail.com (mayank bansal) Date: Tue, 15 Dec 2020 23:17:22 +0530 Subject: Class TreeMap | Lower and Upper Count Support In-Reply-To: <1952229439.1712458.1604837314184.JavaMail.zimbra@u-pem.fr> References: <1632913677.1674462.1604831970061.JavaMail.zimbra@u-pem.fr> <1952229439.1712458.1604837314184.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, I raised a PR for improving the complexity of size() method of HeadMap/ TailMap https://github.com/openjdk/jdk/pull/1255 . I am getting jcheck failed exception because of wrong commit message as it is not yet assigned to any issue id. Could you please help here ? Thanks. On Sun, Nov 8, 2020 at 5:38 PM wrote: > > > ------------------------------ > > *De: *"mayank bansal" > *?: *"Remi Forax" > *Cc: *"core-libs-dev" > *Envoy?: *Dimanche 8 Novembre 2020 12:55:09 > *Objet: *Re: Class TreeMap | Lower and Upper Count Support > > Hi Remi, > Thank you for pointing that out. This is providing the same feature but it > is not the optimal approach for calculating the size. > > AscendingSubMap().size() is actually iterating each and every element > using Iterator to calculate the size resulting in the O(N) time complexity > which can be reduced to O(logN) and this will be a huge improvement. Code > snippet for the reference - > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950 > > I am coming from the fact that I was trying to solve one coding problem, I > tried using own Balanced BST > (AVL tree) and it > executed in ~180ms and when I tried using TreeSet headSet().size() > , it resulted in a > TLE - Time Limit Exceeded. > > > Interesting, I've always though that all collections of java.util had a > size() implementation in O(1). > It may be worth fixing this if there is a simple fix. > > One issue with TreeMap is that unlike most of the other implementations, > TreeMap is not used a lot so we are still discovering issues. > > R?mi > > > > > On Sun, Nov 8, 2020 at 4:09 PM Remi Forax wrote: > >> Is it different from >> headMap(key, true).size() / tailMap(key, true).size() ? >> >> >> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean) >> >> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean) >> >> cheers, >> R?mi >> >> ----- Mail original ----- >> > De: "mayank bansal" >> > ?: "core-libs-dev" >> > Envoy?: Dimanche 8 Novembre 2020 11:22:01 >> > Objet: Class TreeMap | Lower and Upper Count Support >> >> > Hi Everyone, >> > >> > I would like to propose and work on a feature request of supporting the >> > lower and higher count in java class TreeMap. >> > "lower count" is the number of elements that are strictly less than the >> > given value. >> > "upper count" is the number of elements that are strictly greater than >> the >> > given value. >> > >> > *Method definitions-* >> > int getLowerCount(K key); >> > int getHigherCount(K key); >> > >> > *Follow-up feature -* >> > Class TreeSet constructor initializes the TreeMap in the TreeSet >> > constructor. >> > It puts the dummy value as *new Object()* whenever we add the entry in >> > TreeSet. >> > I would like to work on the feature to provide the *Duplicate count* in >> > case of the same Key and the same Value. >> > >> > I will be happy to work on both and raise a PR. I need some guidance if >> the >> > proposed feature looks good and I can start working on it and also would >> > like to know about the process whether I can directly raise the PR. >> > >> > Thanks >> > -- >> > Regards, >> > Mayank Bansal >> > > > -- > Regards, > Mayank Bansal > > -- Regards, Mayank Bansal From martin at openjdk.java.net Tue Dec 15 18:08:01 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 15 Dec 2020 18:08:01 GMT Subject: RFR: 8254350: CompletableFuture.get may swallow InterruptedException [v2] In-Reply-To: References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: <5Jh2S_YOalDQRSdKdF8v9yed0drhWSO2zVbHXOgB7Ho=.aa01ce26-09e8-4a0d-adfa-abfe570ce402@github.com> On Tue, 8 Dec 2020 07:53:17 GMT, Alan Bateman wrote: >> Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > Marked as reviewed by alanb (Reviewer). This change went into jdk16 instead and was automatically forward-ported to jdk, so abandoning this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1651 From martin at openjdk.java.net Tue Dec 15 18:08:03 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 15 Dec 2020 18:08:03 GMT Subject: Withdrawn: 8254350: CompletableFuture.get may swallow InterruptedException In-Reply-To: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> References: <4zhasBpCWU8_SX1YUaSS5z6ELDKXUimxHoGt3JUrDZI=.fa40e3cd-4be2-4d82-b3f1-777605f05095@github.com> Message-ID: On Sun, 6 Dec 2020 22:12:54 GMT, Martin Buchholz wrote: > 8254350: CompletableFuture.get may swallow InterruptedException This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1651 From rriggs at openjdk.java.net Tue Dec 15 18:16:57 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 15 Dec 2020 18:16:57 GMT Subject: RFR: 8251989: Hex formatting and parsing utility [v20] In-Reply-To: References: Message-ID: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: - Correct typos in fromHexDigits methods javadoc - Merge branch 'master' into 8251989-hex-formatter - Merge branch 'master' into 8251989-hex-formatter - Clarified parsing of hex as unsigned in fromHexDigits methods. - Added @apiNote to fromHexDigits methods to link and compare to similar methods in Integer and Long. - Merge branch 'master' into 8251989-hex-formatter - Add class level clarification of use of uppercase for primitive conversions Switched order of declaration of a couple of method to make the javadoc sequence easier to read - Clarify that the fromHexDigit method does not use the prefix, suffix, delimiter, or uppercase parameter. - Clarify that the fromHexDigits does not use the uppercase parameter. - Increased memory to 4G for the test and add diagnostic info for OOME - ... and 23 more: https://git.openjdk.java.net/jdk/compare/912990ca...4866a0a2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/482/files - new: https://git.openjdk.java.net/jdk/pull/482/files/044d4633..4866a0a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=18-19 Stats: 32400 lines in 831 files changed: 23862 ins; 5860 del; 2678 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482 From bchristi at openjdk.java.net Tue Dec 15 18:50:56 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 18:50:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> References: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> Message-ID: <8p4RRf4ltO4wlaOuBRdmlMA-EFGqomUwl2Oat9RwOzw=.95ea6210-d252-4d7a-b316-0384c14b4490@github.com> On Tue, 15 Dec 2020 07:32:12 GMT, Alan Bateman wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> updates, per code review > > test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45: > >> 43: SocketChannel client = SocketChannel.open (); >> 44: client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port)); >> 45: SocketChannel channel = server.accept (); > > Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there). Yes, I will name it, "peer", and remove the extra space on the affected lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From github.com+741251+turbanoff at openjdk.java.net Tue Dec 15 18:58:06 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 15 Dec 2020 18:58:06 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov wrote: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base I believe this changes is useful and still actual: 1. improve code to make it easier to read. 2. performance should be improved a bit too ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From github.com+741251+turbanoff at openjdk.java.net Tue Dec 15 18:58:06 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 15 Dec 2020 18:58:06 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Message-ID: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base ------------- Commit messages: - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.base Changes: https://git.openjdk.java.net/jdk/pull/20/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258422 Stats: 42 lines in 21 files changed: 0 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From smarks at openjdk.java.net Tue Dec 15 18:58:06 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Dec 2020 18:58:06 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Sun, 4 Oct 2020 11:55:50 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > I believe this changes is useful and still actual: > 1. improve code to make it easier to read. > 2. performance should be improved a bit too I?ll see if I can get somebody to take a look at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From chegar at openjdk.java.net Tue Dec 15 18:58:07 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 15 Dec 2020 18:58:07 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Sat, 31 Oct 2020 19:37:10 GMT, Stuart Marks wrote: >> I believe this changes is useful and still actual: >> 1. improve code to make it easier to read. >> 2. performance should be improved a bit too > > I?ll see if I can get somebody to take a look at this. This seems like a reasonable change, which improves readability. My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example: --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -2191,8 +2191,8 @@ public class File * {@code false} otherwise */ public boolean equals(Object obj) { - if ((obj != null) && (obj instanceof File)) { - return compareTo((File)obj) == 0; + if (obj instanceof File file) { + return compareTo(file) == 0; } return false; } ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From github.com+741251+turbanoff at openjdk.java.net Tue Dec 15 18:58:07 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 15 Dec 2020 18:58:07 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Mon, 2 Nov 2020 09:15:31 GMT, Chris Hegarty wrote: >> I?ll see if I can get somebody to take a look at this. > > This seems like a reasonable change, which improves readability. > > My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example: > > --- a/src/java.base/share/classes/java/io/File.java > +++ b/src/java.base/share/classes/java/io/File.java > @@ -2191,8 +2191,8 @@ public class File > * {@code false} otherwise > */ > public boolean equals(Object obj) { > - if ((obj != null) && (obj instanceof File)) { > - return compareTo((File)obj) == 0; > + if (obj instanceof File file) { > + return compareTo(file) == 0; > } > return false; > } Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448 ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From aefimov at openjdk.java.net Tue Dec 15 18:58:07 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 15 Dec 2020 18:58:07 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 2 Dec 2020 20:15:02 GMT, Andrey Turbanov wrote: >> This seems like a reasonable change, which improves readability. >> >> My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example: >> >> --- a/src/java.base/share/classes/java/io/File.java >> +++ b/src/java.base/share/classes/java/io/File.java >> @@ -2191,8 +2191,8 @@ public class File >> * {@code false} otherwise >> */ >> public boolean equals(Object obj) { >> - if ((obj != null) && (obj instanceof File)) { >> - return compareTo((File)obj) == 0; >> + if (obj instanceof File file) { >> + return compareTo(file) == 0; >> } >> return false; >> } > > Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448 Hi @turbanoff, I've logged a JBS issue for tracking this change: https://bugs.openjdk.java.net/browse/JDK-8258422 JEP 394 is finalized now, so I guess you could follow-up Chris suggestion to remove the explicit casts. After the fix is properly reviewed and marked as ready for the integration (you'll need to issue `/integrate` command), once it is done I would happily `/sponsor` the change. With Best Regards, Aleksei ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From jboes at openjdk.java.net Tue Dec 15 19:34:04 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 15 Dec 2020 19:34:04 GMT Subject: [jdk16] RFR: 8257637: Update usage of "type" terminology in java.lang.annotation Message-ID: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> This change is in line with upcoming changes in the JLS terminology ('type' versus 'class and interface'). For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html For easier reviewing, paragraphs will only be reflowed before the PR is integrated. ------------- Commit messages: - revert field name change - two more changes - Merge branch '8257637' of github.com:FrauBoes/jdk16 into 8257637 - intial pass Changes: https://git.openjdk.java.net/jdk16/pull/27/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=27&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257637 Stats: 76 lines in 9 files changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.java.net/jdk16/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk16/pull/27 From github.com+741251+turbanoff at openjdk.java.net Tue Dec 15 19:52:31 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 15 Dec 2020 19:52:31 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v2] In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base use instanceof pattern matching - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/20/files - new: https://git.openjdk.java.net/jdk/pull/20/files/f09bbd24..603cd364 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=00-01 Stats: 784681 lines in 7664 files changed: 596718 ins; 128884 del; 59079 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From darcy at openjdk.java.net Tue Dec 15 19:52:59 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Dec 2020 19:52:59 GMT Subject: [jdk16] RFR: 8257637: Update usage of "type" terminology in java.lang.annotation In-Reply-To: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> References: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> Message-ID: On Tue, 15 Dec 2020 19:28:15 GMT, Julia Boes wrote: > This change is in line with upcoming changes in the JLS terminology ('type' versus 'class and interface'). > > For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > For easier reviewing, paragraphs will only be reflowed before the PR is integrated. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/27 From ihse at openjdk.java.net Tue Dec 15 20:50:54 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 20:50:54 GMT Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From bpb at openjdk.java.net Tue Dec 15 22:00:05 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Dec 2020 22:00:05 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > updates, per code review test/jdk/java/lang/ClassLoader/Assert.java line 65: > 63: > 64: int switchSource = 0; > 65: if (args.length == 0) { // This is the coordinator version Perhaps s/coordinator/controller/? ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From lancea at openjdk.java.net Tue Dec 15 22:04:59 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Dec 2020 22:04:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:57:17 GMT, Brian Burkhalter wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> updates, per code review > > test/jdk/java/lang/ClassLoader/Assert.java line 65: > >> 63: >> 64: int switchSource = 0; >> 65: if (args.length == 0) { // This is the coordinator version > > Perhaps s/coordinator/controller/? Let's change it to: // This is the controller ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 22:05:00 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 22:05:00 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen wrote: >> test/jdk/java/lang/ClassLoader/Assert.java line 65: >> >>> 63: >>> 64: int switchSource = 0; >>> 65: if (args.length == 0) { // This is the coordinator version >> >> Perhaps s/coordinator/controller/? > > Let's change it to: > > // This is the controller Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From smarks at openjdk.java.net Tue Dec 15 22:16:57 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Dec 2020 22:16:57 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v2] In-Reply-To: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> Message-ID: On Tue, 15 Dec 2020 09:17:03 GMT, Magnus Ihse Bursie wrote: >> Your call, I'm not a native English speaker :-) It felt to me it's 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a restrictive allow-list. > > It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former. I'd suggest `... as defining an allow-list that is too narrow or a reject-list that is too-wide may prevent ...`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 22:21:12 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 22:21:12 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with three additional commits since the last revision: - This is the controller - use 'controller' in Assert.java - use 'peer' in CloseRegisteredChannel.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/29525f05..b8cd8b6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From ihse at openjdk.java.net Tue Dec 15 22:40:53 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 22:40:53 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v3] In-Reply-To: References: Message-ID: > 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. > > ### Modules reviewed > > - [ ] java.base > - [ ] java.desktop > - [x] jdk.compiler > - [ ] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move macosxicons from share to macosx ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/f0047704..00dc61c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=01-02 Stats: 1 line in 2 files changed: 0 ins; 0 del; 1 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 From bpb at openjdk.java.net Tue Dec 15 22:46:59 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Dec 2020 22:46:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with three additional commits since the last revision: > > - This is the controller > - use 'controller' in Assert.java > - use 'peer' in CloseRegisteredChannel.java Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From rriggs at openjdk.java.net Tue Dec 15 22:46:58 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 15 Dec 2020 22:46:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with three additional commits since the last revision: > > - This is the controller > - use 'controller' in Assert.java > - use 'peer' in CloseRegisteredChannel.java Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From ihse at openjdk.java.net Tue Dec 15 22:56:15 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 22:56:15 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: > 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. > > ### Modules reviewed > > - [x] java.base > - [ ] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Update comment refering to "make" dir - Move new symbols to jdk.compiler - Merge branch 'master' into shuffle-data - Move macosxicons from share to macosx - Move to share/data, and move jdwp.spec to java.se - Update references in test - Step 2: Update references - First stage, move actual data files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/00dc61c1..68b252b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=02-03 Stats: 38451 lines in 948 files changed: 28535 ins; 6611 del; 3305 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 From ihse at openjdk.java.net Tue Dec 15 22:56:16 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 22:56:16 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Move to share/data, and move jdwp.spec to java.se > > Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall. I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this? > test/jdk/java/util/Locale/LSRDataTest.java line 57: > >> 55: // path to the lsr file from the make folder, this test relies on the >> 56: // relative path to the file in the make folder, considering >> 57: // test and make will always exist in the same jdk layout > > The comment refers to the "make" folder. (line 55 as well). Fixed. Thank you for noticing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From bchristi at openjdk.java.net Tue Dec 15 23:09:55 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 23:09:55 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v3] In-Reply-To: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> Message-ID: On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks wrote: >> It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former. > > I'd suggest `... as defining an allow-list that is too narrow or a reject-list that is too wide may prevent ...`. > > (edited to remove hyphen from "too-wide") Even better! ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Tue Dec 15 23:14:14 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Dec 2020 23:14:14 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: improve SERIAL_FILTER_PATTERN comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/b8cd8b6d..ba586413 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From smarks at openjdk.java.net Tue Dec 15 23:34:59 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Dec 2020 23:34:59 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v3] In-Reply-To: <6MYyTjgru79pTvvR26CIk-Tzo0s_dDgSSbXWUCnfdtk=.0e21f25d-01ba-431b-ac7d-a80c96d488c0@github.com> References: <6MYyTjgru79pTvvR26CIk-Tzo0s_dDgSSbXWUCnfdtk=.0e21f25d-01ba-431b-ac7d-a80c96d488c0@github.com> Message-ID: On Thu, 10 Dec 2020 23:36:13 GMT, Brian Burkhalter wrote: >> Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8248383: Re-indent subclasses in @see tages Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From smarks at openjdk.java.net Tue Dec 15 23:36:58 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Dec 2020 23:36:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > improve SERIAL_FILTER_PATTERN comment Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From asemenyuk at openjdk.java.net Wed Dec 16 00:29:04 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Dec 2020 00:29:04 GMT Subject: [jdk16] RFR: 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 Message-ID: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> Ignore files created by prefs subsystem when checking if source runtime contains the same files as packed runtime. ------------- Commit messages: - 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 Changes: https://git.openjdk.java.net/jdk16/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258293 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/31/head:pull/31 PR: https://git.openjdk.java.net/jdk16/pull/31 From almatvee at openjdk.java.net Wed Dec 16 05:58:57 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 16 Dec 2020 05:58:57 GMT Subject: [jdk16] RFR: 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 In-Reply-To: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> References: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> Message-ID: On Wed, 16 Dec 2020 00:24:20 GMT, Alexey Semenyuk wrote: > Ignore files created by prefs subsystem when checking if source runtime contains the same files as packed runtime. Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/31 From alanb at openjdk.java.net Wed Dec 16 07:13:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Dec 2020 07:13:58 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > improve SERIAL_FILTER_PATTERN comment Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/util/Locale.java line 1649: > 1647: *

This implements the 'Language-Tag' production of BCP47, and > 1648: * so supports legacy (regular and irregular, referred to as > 1649: * {@code Type: grandfathered} in BCP47) as well as You might consider putting quotes around "Type; grandfathered" here, otherwise looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From alanb at openjdk.java.net Wed Dec 16 07:16:00 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Dec 2020 07:16:00 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v2] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: <_LvzyyCLPoXsNJNNlU_qBmje3U5RvwKifXod1bN5Yc8=.b11b4f6e-16e0-4f92-a052-b55dc2fecb33@github.com> On Tue, 15 Dec 2020 19:52:31 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > use instanceof pattern matching > - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 803: > 801: if (obj instanceof WindowsPath path) { > 802: return compareTo(path) == 0; > 803: } Can you do the same in UnixPath? ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From github.com+741251+turbanoff at openjdk.java.net Wed Dec 16 09:20:09 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Dec 2020 09:20:09 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3] In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base use instanceof pattern matching in UnixPath too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/20/files - new: https://git.openjdk.java.net/jdk/pull/20/files/603cd364..0d2ac405 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From jfranck at openjdk.java.net Wed Dec 16 09:44:56 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Dec 2020 09:44:56 GMT Subject: RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly In-Reply-To: References: Message-ID: <_X4yWcZn3bTZvxheU_3KetrVryIV_npRu3lnAzMRILc=.527d5212-fb5c-4555-86ab-758cf03fa06b@github.com> On Fri, 27 Nov 2020 22:37:18 GMT, Rafael Winterhalter wrote: >> @raphw can you take a look at this? > > I just ran it a bit and this seems right to me. I just had an error reported in relation to this and I think this is fixed by your changes, too. (https://github.com/raphw/byte-buddy/issues/983) Moving this to 16, see https://github.com/openjdk/jdk16/pull/33 ------------- PR: https://git.openjdk.java.net/jdk/pull/1414 From jfranck at openjdk.java.net Wed Dec 16 09:44:57 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Dec 2020 09:44:57 GMT Subject: Withdrawn: 8256693: getAnnotatedReceiverType parameterizes types too eagerly In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 15:54:47 GMT, Joel Borggr?n-Franck wrote: > The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1414 From chegar at openjdk.java.net Wed Dec 16 09:47:59 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 16 Dec 2020 09:47:59 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > use instanceof pattern matching in UnixPath too Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow. src/java.base/share/classes/java/net/InetSocketAddress.java line 414: > 412: if (!(obj instanceof InetSocketAddress)) > 413: return false; > 414: return holder.equals(((InetSocketAddress) obj).holder); If we restructure this a little we can get: public final boolean equals(Object obj) { if (obj instanceof InetSocketAddress that) return holder.equals(that.holder); return false; } src/java.base/share/classes/java/net/InetSocketAddress.java line 124: > 122: if (!(obj instanceof InetSocketAddressHolder)) > 123: return false; > 124: InetSocketAddressHolder that = (InetSocketAddressHolder)obj; If we restructure this a little we can take advantage of flow scoping, e.g. public final boolean equals(Object obj) { if (!(obj instanceof InetSocketAddressHolder that)) return false; boolean sameIP; if (addr != null) sameIP = addr.equals(that.addr); else if (hostname != null) sameIP = (that.addr == null) && hostname.equalsIgnoreCase(that.hostname); else sameIP = (that.addr == null) && (that.hostname == null); return sameIP && (port == that.port); } ------------- Changes requested by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/20 From jfranck at openjdk.java.net Wed Dec 16 09:48:10 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Dec 2020 09:48:10 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly Message-ID: The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 ------------- Commit messages: - Add javadoc note explaining empty type arguments array - 8256693: getAnnotatedReceiverType parameterizes types too eagerly Changes: https://git.openjdk.java.net/jdk16/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=33&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256693 Stats: 133 lines in 4 files changed: 106 ins; 22 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/33/head:pull/33 PR: https://git.openjdk.java.net/jdk16/pull/33 From alanb at openjdk.java.net Wed Dec 16 10:15:56 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Dec 2020 10:15:56 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote: >> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall. > > I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this? I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From github.com+741251+turbanoff at openjdk.java.net Wed Dec 16 10:32:12 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Dec 2020 10:32:12 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base take advantage of "flow scoping" to eliminate casts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/20/files - new: https://git.openjdk.java.net/jdk/pull/20/files/0d2ac405..f5727ca9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=02-03 Stats: 42 lines in 12 files changed: 1 ins; 10 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From jboes at openjdk.java.net Wed Dec 16 10:35:13 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Dec 2020 10:35:13 GMT Subject: [jdk16] RFR: 8257637: Update usage of "type" terminology in java.lang.annotation [v2] In-Reply-To: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> References: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> Message-ID: > This change is in line with upcoming changes in the JLS terminology ('type' versus 'class and interface'). > > For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > For easier reviewing, paragraphs will only be reflowed before the PR is integrated. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: reflow paragraphs ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/27/files - new: https://git.openjdk.java.net/jdk16/pull/27/files/aaa64159..c3f47c91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=27&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=27&range=00-01 Stats: 35 lines in 7 files changed: 3 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk16/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk16/pull/27 From jboes at openjdk.java.net Wed Dec 16 10:49:56 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Dec 2020 10:49:56 GMT Subject: [jdk16] Integrated: 8257637: Update usage of "type" terminology in java.lang.annotation In-Reply-To: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> References: <40qJdX-zefHGJpxatANPN6E5UR5WmuESkcUfH_WsB20=.44f84a61-2ad4-4fd1-9ddf-1455edbbaa74@github.com> Message-ID: On Tue, 15 Dec 2020 19:28:15 GMT, Julia Boes wrote: > This change is in line with upcoming changes in the JLS terminology ('type' versus 'class and interface'). > > For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > For easier reviewing, paragraphs will only be reflowed before the PR is integrated. This pull request has now been integrated. Changeset: 72dfba80 Author: Julia Boes URL: https://git.openjdk.java.net/jdk16/commit/72dfba80 Stats: 86 lines in 9 files changed: 3 ins; 0 del; 83 mod 8257637: Update usage of "type" terminology in java.lang.annotation Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk16/pull/27 From martin.doerr at sap.com Wed Dec 16 13:39:17 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Dec 2020 13:39:17 +0000 Subject: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module Message-ID: Hi, JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity. The original change applies cleanly, by javac from 11u has a problem with the new AutomaticModulesTest: AutomaticModulesTest.java:70: error: reference to createJarFile is ambiguous JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES); ^ both method createJarFile(Path,Path,Path...) in JarUtils and method createJarFile(Path,Path,String...) in JarUtils match I suggest to resolve it this way: http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.patch Bug: https://bugs.openjdk.java.net/browse/JDK-8211825 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01 11u webrev: http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.00/ Please review. Best regards, Martin From ihse at openjdk.java.net Wed Dec 16 14:02:57 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Dec 2020 14:02:57 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman wrote: >> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this? > > I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives? @AlanBateman Let me re-iterate: the data files are *not* "make" files. It is just as annoying to have team-specific data files in the make tree! So to keep things as they are is not an option. The fact that they currently reside there is just a continuation of the old view of make as a general dumping ground. I've requested this change since before Project Jigsaw. In fact, I opposed Erik's original Jigsaw patch on this ground, among other things. As a compromise, we agreed that it was to be fixed *after* Jigsaw, since that project had already dragged out in time for so long and was blocking the release. (See https://bugs.openjdk.java.net/browse/JDK-8055193 for details.) So what do you propose for alternative? A new top-level data directory? I mean, sure, we could have like `data/java.base/share/charsetmapping` instead. I personally think that makes less sense. I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From github.com+1059453+fleshgrinder at openjdk.java.net Wed Dec 16 14:44:56 2020 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Wed, 16 Dec 2020 14:44:56 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: Message-ID: <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com> On Mon, 14 Dec 2020 19:36:45 GMT, Roger Riggs wrote: > There is very little value in adding the exception doing so might prevent existing applications from continuing to function. I disagree on the value and am with the author of the original issue. All these existing applications are functioning but factually invalid, adding the exception like we have it in all other methods of the class would surface the issue in exactly those applications. ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From rriggs at openjdk.java.net Wed Dec 16 14:57:57 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Dec 2020 14:57:57 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v3] In-Reply-To: <6MYyTjgru79pTvvR26CIk-Tzo0s_dDgSSbXWUCnfdtk=.0e21f25d-01ba-431b-ac7d-a80c96d488c0@github.com> References: <6MYyTjgru79pTvvR26CIk-Tzo0s_dDgSSbXWUCnfdtk=.0e21f25d-01ba-431b-ac7d-a80c96d488c0@github.com> Message-ID: On Thu, 10 Dec 2020 23:36:13 GMT, Brian Burkhalter wrote: >> Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8248383: Re-indent subclasses in @see tages Somewhat odd that the files changed includes merged file from a different changeset but seems immaterial to the changes for the issue. test/jdk/java/io/Reader/ReadIntoZeroLengthArray.java line 39: > 37: */ > 38: public class ReadIntoZeroLengthArray { > 39: private static char[] cbuf0 = new char[0]; I would encourage the use of TestNG for new tests and they provide a good DataProvider framework for multiple test cases. (And frequently they run more quickly because they can be run in the jtreg process without spawing a separate process). ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1737 From jboes at openjdk.java.net Wed Dec 16 15:22:08 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Dec 2020 15:22:08 GMT Subject: [jdk16] RFR: 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect Message-ID: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> Another change to align with upcoming changes in the JLS terminology ('type' versus 'class and interface'). For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html Where a class models types (as in the type of a variable or an expression), the change in terminology is mostly not applicable. For easier reviewing, paragraphs will only be reflowed before the PR is integrated. ------------- Commit messages: - first pass - update java.lang.Class Changes: https://git.openjdk.java.net/jdk16/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257636 Stats: 56 lines in 14 files changed: 0 ins; 1 del; 55 mod Patch: https://git.openjdk.java.net/jdk16/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk16/pull/36 From vromero at openjdk.java.net Wed Dec 16 16:34:08 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 16 Dec 2020 16:34:08 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggr?n-Franck wrote: > The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. > > See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 Changes requested by vromero (Reviewer). test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java line 181: > 179: if (failures != 0) > 180: throw new RuntimeException("Test failed, see log for details"); > 181: else if (tests != 25) this looks a bit brittle, isn't it better to count the number of tests failing and issue an error if that number is > 0? ------------- PR: https://git.openjdk.java.net/jdk16/pull/33 From philippe.marschall at gmail.com Mon Dec 14 19:31:46 2020 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Mon, 14 Dec 2020 20:31:46 +0100 Subject: Optimization potential in Reader#read(CharBuffer) In-Reply-To: References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: On Fri, Dec 11, 2020 at 5:35 PM Brian Burkhalter wrote: > > Hello, > > ... > > > I think perhaps they could all go in the same PR as the things are quite related. It would be good to have simple JMH benchmarks to measure the improvements. The benchmark code does not necessarily have to be in the PR, i.e., checked in. > That works for me. Philippe From bpb at openjdk.java.net Wed Dec 16 17:16:14 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Dec 2020 17:16:14 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v4] In-Reply-To: References: Message-ID: <-r_M0r8YJQLXI7_qiwYr8hnAHuEYJscRCeeAu_qhQeA=.7d6ced2d-2cd0-4ae4-81be-a375953446b3@github.com> > Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8248383: Convert test ReadIntoZeroLengthArray to TestNG ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1737/files - new: https://git.openjdk.java.net/jdk/pull/1737/files/7fbc77f7..ab73f98d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1737&range=02-03 Stats: 43 lines in 1 file changed: 21 ins; 7 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/1737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1737/head:pull/1737 PR: https://git.openjdk.java.net/jdk/pull/1737 From bpb at openjdk.java.net Wed Dec 16 17:16:15 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Dec 2020 17:16:15 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v3] In-Reply-To: References: <6MYyTjgru79pTvvR26CIk-Tzo0s_dDgSSbXWUCnfdtk=.0e21f25d-01ba-431b-ac7d-a80c96d488c0@github.com> Message-ID: On Wed, 16 Dec 2020 14:52:39 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8248383: Re-indent subclasses in @see tages > > test/jdk/java/io/Reader/ReadIntoZeroLengthArray.java line 39: > >> 37: */ >> 38: public class ReadIntoZeroLengthArray { >> 39: private static char[] cbuf0 = new char[0]; > > I would encourage the use of TestNG for new tests and they provide a good DataProvider framework for multiple test cases. (And frequently they run more quickly because they can be run in the jtreg process without spawing a separate process). I think the extra commits are because I put some commits on the master branch and then merged them into the feature branch. I believe the integration will merge them correctly. I converted the test to TestNG. I've used it a number of times before to good effect (cf. java/nio/Buffer/BulkPutBuffer.java) but was too lazy to review the annotations again. Thanks for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From aph at openjdk.java.net Wed Dec 16 17:35:59 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 16 Dec 2020 17:35:59 GMT Subject: RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v4] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 07:52:14 GMT, Nick Gasson wrote: >> This is more-or-less a straight port of the x86 code to AArch64. >> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() >> to generate a blob that jumps to the native function entry point. This >> simply switches the thread state from Java to native and handles the >> safepoint poll on return from native code. >> >> AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame >> pointer) may hold a live oop over the MachCallNative node. Normally this >> would be saved by RegisterSaver::save_live_registers() but the native >> invoker blob is not a "proper" stub routine so doesn't have an oop map. >> I copied the x86 solution to this where the frame pointer register is >> saved to the stack and a pointer to that is stored in the frame anchor. >> This is then read back and added to the register map when walking the >> stack. I saw in the PR comments [1] that this might be a temporary fix, >> but I'm not sure if there's any plan to change that now? >> >> Another potential fix might be to change the C2 register definition of >> R29 and R29_H to be save-on-call as below. This works for the >> TestStackWalk.java test case but I don't know whether it has other >> unintended side-effects. >> >> reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp >> reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); >> >> JMH results from jdk/incubator/foreign/CallOverhead.java to show it's >> working: >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op >> CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op >> CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op >> CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op >> CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op >> CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op >> CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op >> CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op >> CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op >> >> -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: >> >> Benchmark Mode Cnt Score Error Units >> CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op >> CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op >> CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op >> CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op >> CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op >> CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op >> CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op >> CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op >> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op >> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op >> >> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Release-store to thread state and fix safepoint_poll args Looks good to me. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1711 From rriggs at openjdk.java.net Wed Dec 16 17:38:58 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Dec 2020 17:38:58 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v4] In-Reply-To: <-r_M0r8YJQLXI7_qiwYr8hnAHuEYJscRCeeAu_qhQeA=.7d6ced2d-2cd0-4ae4-81be-a375953446b3@github.com> References: <-r_M0r8YJQLXI7_qiwYr8hnAHuEYJscRCeeAu_qhQeA=.7d6ced2d-2cd0-4ae4-81be-a375953446b3@github.com> Message-ID: <2JP6FCY0TNze78ZHT8XtyKTMqHYP6_IU0khN1uyTUrI=.03823be9-19d0-4f89-bca8-5c6fa37eb507@github.com> On Wed, 16 Dec 2020 17:16:14 GMT, Brian Burkhalter wrote: >> Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8248383: Convert test ReadIntoZeroLengthArray to TestNG Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From aefimov at openjdk.java.net Wed Dec 16 18:29:56 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 16 Dec 2020 18:29:56 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 09:44:37 GMT, Chris Hegarty wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base >> use instanceof pattern matching in UnixPath too > > Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow. Hi Andrey, Could you, please, also take a look at `java.net.Socket`: java/net/Socket.java: if (bindpoint != null && (!(bindpoint instanceof InetSocketAddress))) java/net/Socket.java- throw new IllegalArgumentException("Unsupported address type"); And `HttpURLConnection`: sun/net/www/protocol/http/HttpURLConnection.java: if (a != null && c instanceof HttpURLConnection) { sun/net/www/protocol/http/HttpURLConnection.java- ((HttpURLConnection)c).setAuthenticator(a); The following cmd was used to find them: `rgrep -A 1 "= null .* instanceof "` ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From naoto at openjdk.java.net Wed Dec 16 18:37:00 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Dec 2020 18:37:00 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Move to share/data, and move jdwp.spec to java.se > > Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall. >I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is. Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From github.com+741251+turbanoff at openjdk.java.net Wed Dec 16 19:22:01 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Dec 2020 19:22:01 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 18:27:35 GMT, Aleksei Efimov wrote: >> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow. > > Hi Andrey, > > Could you, please, also take a look at `java.net.Socket`: > java/net/Socket.java: if (bindpoint != null && (!(bindpoint instanceof InetSocketAddress))) > java/net/Socket.java- throw new IllegalArgumentException("Unsupported address type"); > And `HttpURLConnection`: > sun/net/www/protocol/http/HttpURLConnection.java: if (a != null && c instanceof HttpURLConnection) { > sun/net/www/protocol/http/HttpURLConnection.java- ((HttpURLConnection)c).setAuthenticator(a); > The following cmd was used to find them: `rgrep -A 1 "= null .* instanceof "` @AlekseiEfimov in both cases removing `null` check will change semantic of the code. Comparison is not redundant. ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From jfranck at openjdk.java.net Wed Dec 16 19:59:59 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Dec 2020 19:59:59 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly In-Reply-To: References: Message-ID: <1akeoloOPbnRLP9pjaw1WoLoaGhhKCQmZUBBZcBr_zg=.0369f754-239f-4634-8597-bad69ad12ee7@github.com> On Wed, 16 Dec 2020 16:26:37 GMT, Vicente Romero wrote: >> The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. >> >> This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. >> >> See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 > > test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java line 181: > >> 179: if (failures != 0) >> 180: throw new RuntimeException("Test failed, see log for details"); >> 181: else if (tests != 25) > > this looks a bit brittle, isn't it better to count the number of tests failing and issue an error if that number is > 0? Yes, not great, but at least it isn't brittle when running the test, only when changing it. I'd like to take a separate pass over the tests for 17 if possible. ------------- PR: https://git.openjdk.java.net/jdk16/pull/33 From bchristi at openjdk.java.net Wed Dec 16 20:00:59 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Dec 2020 20:00:59 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v4] In-Reply-To: References: Message-ID: <_3eyagnLPeaqOmlVW65dLaW-Wml-BqQHSAtqFGgtzcE=.1168634c-3ed4-457a-867c-5d8bcd0d12c1@github.com> On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> improve SERIAL_FILTER_PATTERN comment > > src/java.base/share/classes/java/util/Locale.java line 1649: > >> 1647: *

This implements the 'Language-Tag' production of BCP47, and >> 1648: * so supports legacy (regular and irregular, referred to as >> 1649: * {@code Type: grandfathered} in BCP47) as well as > > You might consider putting quotes around "Type; grandfathered" here, otherwise looks good. Yes, having that in quotes instead of in {@code} would be consistent with the rest of Locale.java. I will change that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From bchristi at openjdk.java.net Wed Dec 16 20:08:11 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Dec 2020 20:08:11 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v5] In-Reply-To: References: Message-ID: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Use quotes instead of @code in Locale ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/ba586413..03264330 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771 From rriggs at openjdk.java.net Wed Dec 16 20:33:04 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Dec 2020 20:33:04 GMT Subject: Integrated: 8251989: Hex formatting and parsing utility In-Reply-To: References: Message-ID: <2Mw2dY6jYRlke67fIrQXz282V_60eriHaLzzY8Q6aG8=.bec4872c-4a5f-4654-8fda-9f4a79d7e456@github.com> On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs wrote: > java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with modified parameters. > - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex > - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... > - Prefix and suffixes now apply to each formatted value, not the string as a whole > - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams > like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) > - Immutable and thread safe, a "value-based" class > > See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. > > Review comments and suggestions welcome. This pull request has now been integrated. Changeset: aa9c136d Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/aa9c136d Stats: 2065 lines in 14 files changed: 1898 ins; 144 del; 23 mod 8251989: Hex formatting and parsing utility Reviewed-by: tvaleev, chegar, naoto, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/482 From vromero at openjdk.java.net Wed Dec 16 21:23:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 16 Dec 2020 21:23:58 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly In-Reply-To: <1akeoloOPbnRLP9pjaw1WoLoaGhhKCQmZUBBZcBr_zg=.0369f754-239f-4634-8597-bad69ad12ee7@github.com> References: <1akeoloOPbnRLP9pjaw1WoLoaGhhKCQmZUBBZcBr_zg=.0369f754-239f-4634-8597-bad69ad12ee7@github.com> Message-ID: On Wed, 16 Dec 2020 19:57:32 GMT, Joel Borggr?n-Franck wrote: > Yes, not great, but at least it isn't brittle when running the test, only when changing it. I'd like to take a separate pass over the tests for 17 if possible. what about declaring a static final field for that value instead of using a literal? ------------- PR: https://git.openjdk.java.net/jdk16/pull/33 From smarks at openjdk.java.net Wed Dec 16 22:17:56 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Dec 2020 22:17:56 GMT Subject: RFR: 8253497: Core Libs Terminology Refresh [v5] In-Reply-To: References: Message-ID: <7eyzI35LC0CuYkwMo5nfLC8CrEZxmIcX8GfbSKy91MI=.d3322944-9580-410c-b387-490742c36c5a@github.com> On Wed, 16 Dec 2020 20:08:11 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Use quotes instead of @code in Locale Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From jjg at openjdk.java.net Wed Dec 16 22:30:56 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Dec 2020 22:30:56 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 09:11:31 GMT, Hannes Walln?fer wrote: >> This is for JDK16, as a precursor to fixing JDK-8258002. >> >> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. >> >> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40: > >> 38: var MIN_RESULTS = 3; >> 39: var MAX_RESULTS = 500; >> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##"; > > `` is not a string that is ever shown to the user, it is what is used by javadoc to denote the default package (see `toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't be localized as that would break behaviour for code in the default package (and show the localized string as package name, instead of no package name). Noted, thanks ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From bchristi at openjdk.java.net Wed Dec 16 23:12:55 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Dec 2020 23:12:55 GMT Subject: Integrated: 8253497: Core Libs Terminology Refresh In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. This pull request has now been integrated. Changeset: b2f03554 Author: Brent Christian URL: https://git.openjdk.java.net/jdk/commit/b2f03554 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod 8253497: Core Libs Terminology Refresh Reviewed-by: naoto, kcr, rriggs, joehw, bpb, smarks, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1771 From jjg at openjdk.java.net Wed Dec 16 23:21:11 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Dec 2020 23:21:11 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v2] In-Reply-To: References: Message-ID: <1GIodXJQxB1mO27Of0bxkkihV_wRhbb3EoGTnCFWG3w=.f927c17d-3653-4d58-9210-dc5b692386b8@github.com> > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into localize.search.js - JDK-8247994: Localize javadoc search ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/16/files - new: https://git.openjdk.java.net/jdk16/pull/16/files/8eb7f27b..ec111185 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=00-01 Stats: 1532 lines in 52 files changed: 1207 ins; 121 del; 204 mod Patch: https://git.openjdk.java.net/jdk16/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk16/pull/16 From smarks at openjdk.java.net Thu Dec 17 00:48:57 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 17 Dec 2020 00:48:57 GMT Subject: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v2] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 00:32:44 GMT, Paul Sandoz wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo, clarify asserts disabled, test prefGrowth==0 > > Marked as reviewed by psandoz (Reviewer). @Martin-Buchholz Any comments on this? ------------- PR: https://git.openjdk.java.net/jdk/pull/1617 From smarks at openjdk.java.net Thu Dec 17 01:07:05 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 17 Dec 2020 01:07:05 GMT Subject: [jdk16] RFR: 8258259: Unicode linebreak matching behavior is incorrect; backout JDK-8235812 Message-ID: Back out code changes from JDK-8235812 to restore correct matching behavior. Adjust test to comment out cases that tested for incorrect behavior. ------------- Commit messages: - 8258259: Unicode linebreak matching behavior is incorrect; backout JDK-8235812 Changes: https://git.openjdk.java.net/jdk16/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=40&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258259 Stats: 85 lines in 2 files changed: 8 ins; 56 del; 21 mod Patch: https://git.openjdk.java.net/jdk16/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/40/head:pull/40 PR: https://git.openjdk.java.net/jdk16/pull/40 From smarks at openjdk.java.net Thu Dec 17 01:54:57 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 17 Dec 2020 01:54:57 GMT Subject: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array [v4] In-Reply-To: <-r_M0r8YJQLXI7_qiwYr8hnAHuEYJscRCeeAu_qhQeA=.7d6ced2d-2cd0-4ae4-81be-a375953446b3@github.com> References: <-r_M0r8YJQLXI7_qiwYr8hnAHuEYJscRCeeAu_qhQeA=.7d6ced2d-2cd0-4ae4-81be-a375953446b3@github.com> Message-ID: On Wed, 16 Dec 2020 17:16:14 GMT, Brian Burkhalter wrote: >> Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8248383: Convert test ReadIntoZeroLengthArray to TestNG Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From jwilhelm at openjdk.java.net Thu Dec 17 02:59:10 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Dec 2020 02:59:10 GMT Subject: RFR: Merge jdk16 Message-ID: Merge JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258338: Support deprecated records - 8241353: NPE in ToolProvider.getSystemJavaCompiler - 8255880: UI of Swing components is not redrawn after their internal state changed - 8257637: Update usage of "type" terminology in java.lang.annotation - 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive - 8258419: RSA cipher buffer cleanup - 8258380: [JVMCI] don't clear InstalledCode reference when unloading JVMCI nmethods - 8258427: Problem List some tests related to FileDialog for MacOS - 8258140: Update @jls tags in java.base for renamed/renumbered sections - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b2f03554...951fc9c0 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1812&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1812&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1812/files Stats: 882 lines in 41 files changed: 659 ins; 30 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/1812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1812/head:pull/1812 PR: https://git.openjdk.java.net/jdk/pull/1812 From jwilhelm at openjdk.java.net Thu Dec 17 03:08:57 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Dec 2020 03:08:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <6qEv2eY0O11uVLbYwNrAVT7U4LFVK5INiyqa2hByAyQ=.5b8cb7e1-d127-487a-91fc-a1a65e4786b3@github.com> On Thu, 17 Dec 2020 02:48:38 GMT, Jesper Wilhelmsson wrote: > Merge JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 11bd7a81 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/11bd7a81 Stats: 882 lines in 41 files changed: 659 ins; 30 del; 193 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1812 From ngasson at openjdk.java.net Thu Dec 17 03:27:58 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 17 Dec 2020 03:27:58 GMT Subject: Integrated: 8257882: Implement linkToNative intrinsic on AArch64 In-Reply-To: References: Message-ID: <1_lo9ZLUqZjfbNSXFmZYmvvble6HL4iNYbKyUH3GIRE=.9dffe97e-0b5c-43e9-85a5-bf8a98e1890e@github.com> On Wed, 9 Dec 2020 08:20:38 GMT, Nick Gasson wrote: > This is more-or-less a straight port of the x86 code to AArch64. > GraphKit::make_native_call() calls SharedRuntime::make_native_invoker() > to generate a blob that jumps to the native function entry point. This > simply switches the thread state from Java to native and handles the > safepoint poll on return from native code. > > AArch64 suffers the same problem as x86 in JDK-8251047 where R29 (frame > pointer) may hold a live oop over the MachCallNative node. Normally this > would be saved by RegisterSaver::save_live_registers() but the native > invoker blob is not a "proper" stub routine so doesn't have an oop map. > I copied the x86 solution to this where the frame pointer register is > saved to the stack and a pointer to that is stored in the frame anchor. > This is then read back and added to the register map when walking the > stack. I saw in the PR comments [1] that this might be a temporary fix, > but I'm not sure if there's any plan to change that now? > > Another potential fix might be to change the C2 register definition of > R29 and R29_H to be save-on-call as below. This works for the > TestStackWalk.java test case but I don't know whether it has other > unintended side-effects. > > reg_def R29 ( SOC, NS, Op_RegI, 29, r29->as_VMReg() ); // fp > reg_def R29_H ( SOC, NS, Op_RegI, 29, r29->as_VMReg()->next()); > > JMH results from jdk/incubator/foreign/CallOverhead.java to show it's > working: > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=false: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.450 ? 0.363 ns/op > CallOverhead.jni_identity avgt 30 54.145 ? 0.627 ns/op > CallOverhead.panama_args10 avgt 30 1914.431 ? 73.771 ns/op > CallOverhead.panama_args5 avgt 30 1394.274 ? 49.369 ns/op > CallOverhead.panama_blank avgt 30 872.878 ? 20.716 ns/op > CallOverhead.panama_blank_trivial avgt 30 873.852 ? 21.350 ns/op > CallOverhead.panama_identity avgt 30 1058.729 ? 20.229 ns/op > CallOverhead.panama_identity_memory_address avgt 30 1041.648 ? 22.930 ns/op > CallOverhead.panama_identity_struct avgt 30 3212.483 ? 151.627 ns/op > CallOverhead.panama_identity_trivial avgt 30 1056.398 ? 18.779 ns/op > > -Djdk.internal.foreign.ProgrammableInvoker.USE_INTRINSICS=true: > > Benchmark Mode Cnt Score Error Units > CallOverhead.jni_blank avgt 30 51.519 ? 0.345 ns/op > CallOverhead.jni_identity avgt 30 54.689 ? 0.687 ns/op > CallOverhead.panama_args10 avgt 30 42.856 ? 0.760 ns/op > CallOverhead.panama_args5 avgt 30 42.192 ? 0.712 ns/op > CallOverhead.panama_blank avgt 30 41.934 ? 0.349 ns/op > CallOverhead.panama_blank_trivial avgt 30 2.806 ? 0.545 ns/op > CallOverhead.panama_identity avgt 30 44.043 ? 0.398 ns/op > CallOverhead.panama_identity_memory_address avgt 30 45.021 ? 0.409 ns/op > CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750 ns/op > CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651 ns/op > > [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326 This pull request has now been integrated. Changeset: 643ddc13 Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/643ddc13 Stats: 280 lines in 13 files changed: 223 ins; 14 del; 43 mod 8257882: Implement linkToNative intrinsic on AArch64 Reviewed-by: jvernee, mcimadamore, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/1711 From darcy at openjdk.java.net Thu Dec 17 05:30:56 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Dec 2020 05:30:56 GMT Subject: [jdk16] RFR: 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect In-Reply-To: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> References: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> Message-ID: On Wed, 16 Dec 2020 15:17:57 GMT, Julia Boes wrote: > Another change to align with upcoming changes in the JLS terminology ('type' versus 'class and interface'). > > For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > Where a class models types (as in the type of a variable or an expression), the change in terminology is mostly not applicable. For easier reviewing, paragraphs will only be reflowed before the PR is integrated. Marked as reviewed by darcy (Reviewer). src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 209: > 207: * > 208: * @param classes an array of classes or interfaces > 209: * @return the array of class and interface names; or null if classes is empty Slightly better as "...or null if classes is null or empty". ------------- PR: https://git.openjdk.java.net/jdk16/pull/36 From chegar at openjdk.java.net Thu Dec 17 09:51:58 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 17 Dec 2020 09:51:58 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: <8e6vsmTl1qRfnmuLSFn30Yy9ck2SJVcBjdR_flRzB60=.65cd22bb-6d0e-400b-a919-d9634c0f988a@github.com> On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > take advantage of "flow scoping" to eliminate casts Looks good to me. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/20 From jfranck at openjdk.java.net Thu Dec 17 10:07:13 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Thu, 17 Dec 2020 10:07:13 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2] In-Reply-To: References: Message-ID: <34Ai7roPnyyAE9rs90cGsOaC6Y_RUo1RgGEbOSQkBxM=.8cf87ffd-dac4-4ce6-80ea-4d4a4145c195@github.com> > The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. > > See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: Use constant for expected cases ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/33/files - new: https://git.openjdk.java.net/jdk16/pull/33/files/c04169d8..99e03115 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=33&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=33&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/33/head:pull/33 PR: https://git.openjdk.java.net/jdk16/pull/33 From jfranck at openjdk.java.net Thu Dec 17 10:07:14 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Thu, 17 Dec 2020 10:07:14 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2] In-Reply-To: References: <1akeoloOPbnRLP9pjaw1WoLoaGhhKCQmZUBBZcBr_zg=.0369f754-239f-4634-8597-bad69ad12ee7@github.com> Message-ID: On Wed, 16 Dec 2020 21:21:19 GMT, Vicente Romero wrote: >> Yes, not great, but at least it isn't brittle when running the test, only when changing it. I'd like to take a separate pass over the tests for 17 if possible. > >> Yes, not great, but at least it isn't brittle when running the test, only when changing it. I'd like to take a separate pass over the tests for 17 if possible. > > what about declaring a static final field for that value instead of using a literal? Done ------------- PR: https://git.openjdk.java.net/jdk16/pull/33 From github.com+10835776+stsypanov at openjdk.java.net Thu Dec 17 10:19:02 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Dec 2020 10:19:02 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll Message-ID: Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. Currently `Collections.addAll()` is implemented and documented as: /** * ... * The behavior of this convenience method is identical to that of * {@code c.addAll(Arrays.asList(elements))}, but this method is likely * to run significantly faster under most implementations. */ @SafeVarargs public static boolean addAll(Collection c, T... elements) { boolean result = false; for (T element : elements) result |= c.add(element); return result; } But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: (collection) (size) Score Error Units addAll ArrayList 10 37.9 ? 1.9 ns/op addAll ArrayList 100 83.8 ? 3.4 ns/op addAll ArrayList 1000 678.2 ? 23.0 ns/op collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op addAll HashSet 10 128.4 ? 5.9 ns/op addAll HashSet 100 1864.2 ? 102.4 ns/op addAll HashSet 1000 16615.5 ? 1202.6 ns/op collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op addAll ArrayDeque 10 54.0 ? 0.4 ns/op addAll ArrayDeque 100 319.7 ? 2.5 ns/op addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. ------------- Commit messages: - Collections:addAll: instead of one-by-one add elements in bulk Changes: https://git.openjdk.java.net/jdk/pull/1764/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193031 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764 PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+10835776+stsypanov at openjdk.java.net Thu Dec 17 10:19:03 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Dec 2020 10:19:03 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 12:13:23 GMT, ?????? ??????? wrote: > Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this convenience method is identical to that of > * {@code c.addAll(Arrays.asList(elements))}, but this method is likely > * to run significantly faster under most implementations. > */ > @SafeVarargs > public static boolean addAll(Collection c, T... elements) { > boolean result = false; > for (T element : elements) > result |= c.add(element); > return result; > } > > But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: > (collection) (size) Score Error Units > addAll ArrayList 10 37.9 ? 1.9 ns/op > addAll ArrayList 100 83.8 ? 3.4 ns/op > addAll ArrayList 1000 678.2 ? 23.0 ns/op > collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op > collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op > collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op > > addAll HashSet 10 128.4 ? 5.9 ns/op > addAll HashSet 100 1864.2 ? 102.4 ns/op > addAll HashSet 1000 16615.5 ? 1202.6 ns/op > collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op > collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op > collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op > > addAll ArrayDeque 10 54.0 ? 0.4 ns/op > addAll ArrayDeque 100 319.7 ? 2.5 ns/op > addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op > collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op > collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op > collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op > > addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op > addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op > addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op > collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op > collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op > collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op > > addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op > addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op > addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op > collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op > collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op > collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op > > addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op > > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op > > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op > There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. > > So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. Looks like I've found the original ticket: https://bugs.openjdk.java.net/browse/JDK-8193031 ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From alanb at openjdk.java.net Thu Dec 17 10:33:00 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Dec 2020 10:33:00 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > take advantage of "flow scoping" to eliminate casts src/java.base/share/classes/jdk/internal/misc/Signal.java line 102: > 100: */ > 101: public boolean equals(Object other) { > 102: if (this == other) { It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1. ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From github.com+10835776+stsypanov at openjdk.java.net Thu Dec 17 10:33:05 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Dec 2020 10:33:05 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: > Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this convenience method is identical to that of > * {@code c.addAll(Arrays.asList(elements))}, but this method is likely > * to run significantly faster under most implementations. > */ > @SafeVarargs > public static boolean addAll(Collection c, T... elements) { > boolean result = false; > for (T element : elements) > result |= c.add(element); > return result; > } > > But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: > (collection) (size) Score Error Units > addAll ArrayList 10 37.9 ? 1.9 ns/op > addAll ArrayList 100 83.8 ? 3.4 ns/op > addAll ArrayList 1000 678.2 ? 23.0 ns/op > collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op > collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op > collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op > > addAll HashSet 10 128.4 ? 5.9 ns/op > addAll HashSet 100 1864.2 ? 102.4 ns/op > addAll HashSet 1000 16615.5 ? 1202.6 ns/op > collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op > collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op > collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op > > addAll ArrayDeque 10 54.0 ? 0.4 ns/op > addAll ArrayDeque 100 319.7 ? 2.5 ns/op > addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op > collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op > collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op > collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op > > addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op > addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op > addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op > collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op > collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op > collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op > > addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op > addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op > addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op > collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op > collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op > collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op > > addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op > > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op > > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op > There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. > > So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8193031: add elements in bulk in Collections.addAll() ------------- Changes: https://git.openjdk.java.net/jdk/pull/1764/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=01 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764 PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+828220+forax at openjdk.java.net Thu Dec 17 10:38:56 2020 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Dec 2020 10:38:56 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 10:15:23 GMT, ?????? ??????? wrote: >> Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. >> >> Currently `Collections.addAll()` is implemented and documented as: >> /** >> * ... >> * The behavior of this convenience method is identical to that of >> * {@code c.addAll(Arrays.asList(elements))}, but this method is likely >> * to run significantly faster under most implementations. >> */ >> @SafeVarargs >> public static boolean addAll(Collection c, T... elements) { >> boolean result = false; >> for (T element : elements) >> result |= c.add(element); >> return result; >> } >> >> But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: >> (collection) (size) Score Error Units >> addAll ArrayList 10 37.9 ? 1.9 ns/op >> addAll ArrayList 100 83.8 ? 3.4 ns/op >> addAll ArrayList 1000 678.2 ? 23.0 ns/op >> collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op >> collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op >> collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op >> >> addAll HashSet 10 128.4 ? 5.9 ns/op >> addAll HashSet 100 1864.2 ? 102.4 ns/op >> addAll HashSet 1000 16615.5 ? 1202.6 ns/op >> collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op >> collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op >> collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op >> >> addAll ArrayDeque 10 54.0 ? 0.4 ns/op >> addAll ArrayDeque 100 319.7 ? 2.5 ns/op >> addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op >> collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op >> collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op >> collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op >> >> addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op >> addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op >> addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op >> collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op >> collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op >> collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op >> >> addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op >> addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op >> addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op >> collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op >> collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op >> collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op >> >> addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op >> >> addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op >> collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op >> >> addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op >> >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op >> >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op >> There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. >> >> So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. > > Looks like I've found the original ticket: https://bugs.openjdk.java.net/browse/JDK-8193031 Apart from the @SuppressWarnings, this looks good to me. And i like the irony of this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+828220+forax at openjdk.java.net Thu Dec 17 10:38:59 2020 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Dec 2020 10:38:59 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 10:33:05 GMT, ?????? ??????? wrote: >> Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. >> >> Currently `Collections.addAll()` is implemented and documented as: >> /** >> * ... >> * The behavior of this convenience method is identical to that of >> * {@code c.addAll(Arrays.asList(elements))}, but this method is likely >> * to run significantly faster under most implementations. >> */ >> @SafeVarargs >> public static boolean addAll(Collection c, T... elements) { >> boolean result = false; >> for (T element : elements) >> result |= c.add(element); >> return result; >> } >> >> But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: >> (collection) (size) Score Error Units >> addAll ArrayList 10 37.9 ? 1.9 ns/op >> addAll ArrayList 100 83.8 ? 3.4 ns/op >> addAll ArrayList 1000 678.2 ? 23.0 ns/op >> collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op >> collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op >> collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op >> >> addAll HashSet 10 128.4 ? 5.9 ns/op >> addAll HashSet 100 1864.2 ? 102.4 ns/op >> addAll HashSet 1000 16615.5 ? 1202.6 ns/op >> collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op >> collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op >> collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op >> >> addAll ArrayDeque 10 54.0 ? 0.4 ns/op >> addAll ArrayDeque 100 319.7 ? 2.5 ns/op >> addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op >> collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op >> collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op >> collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op >> >> addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op >> addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op >> addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op >> collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op >> collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op >> collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op >> >> addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op >> addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op >> addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op >> collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op >> collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op >> collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op >> >> addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op >> >> addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op >> collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op >> >> addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op >> >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op >> >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op >> There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. >> >> So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8193031: add elements in bulk in Collections.addAll() src/java.base/share/classes/java/util/Collections.java line 5589: > 5587: */ > 5588: @SafeVarargs > 5589: @SuppressWarnings("varargs") I don't think you need a SuppressWarnings here ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From jboes at openjdk.java.net Thu Dec 17 10:44:12 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 17 Dec 2020 10:44:12 GMT Subject: [jdk16] RFR: 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect [v2] In-Reply-To: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> References: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> Message-ID: > Another change to align with upcoming changes in the JLS terminology ('type' versus 'class and interface'). > > For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > Where a class models types (as in the type of a variable or an expression), the change in terminology is mostly not applicable. For easier reviewing, paragraphs will only be reflowed before the PR is integrated. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: reflow paragraphs and adjust 1 change ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/36/files - new: https://git.openjdk.java.net/jdk16/pull/36/files/ef9aed70..b2540e11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=36&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=36&range=00-01 Stats: 34 lines in 9 files changed: 2 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk16/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk16/pull/36 From github.com+10835776+stsypanov at openjdk.java.net Thu Dec 17 10:47:57 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Dec 2020 10:47:57 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 10:34:38 GMT, R?mi Forax wrote: >> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8193031: add elements in bulk in Collections.addAll() > > src/java.base/share/classes/java/util/Collections.java line 5589: > >> 5587: */ >> 5588: @SafeVarargs >> 5589: @SuppressWarnings("varargs") > > I don't think you need a SuppressWarnings here Hi, without this I get failed build: Compiling 3057 files for java.base Compiling 89 properties into resource bundles for java.desktop return c.addAll(Arrays.asList(elements)); ^ error: warnings found and -Werror specified 1 error 1 warning make[3]: *** [/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 CompileJavaModules.gmk:604: recipe for target '/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch' failed make[2]: *** [java.base-java] Error 2 make[2]: *** Waiting for unfinished jobs.... make/Main.gmk:193: recipe for target 'java.base-java' failed ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+828220+forax at openjdk.java.net Thu Dec 17 10:52:57 2020 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Dec 2020 10:52:57 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 10:45:17 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/util/Collections.java line 5589: >> >>> 5587: */ >>> 5588: @SafeVarargs >>> 5589: @SuppressWarnings("varargs") >> >> I don't think you need a SuppressWarnings here > > Hi, without this I get failed build: > Compiling 3057 files for java.base > Compiling 89 properties into resource bundles for java.desktop > > return c.addAll(Arrays.asList(elements)); > ^ > error: warnings found and -Werror specified > 1 error > 1 warning > make[3]: *** [/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 > CompileJavaModules.gmk:604: recipe for target '/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch' failed > make[2]: *** [java.base-java] Error 2 > make[2]: *** Waiting for unfinished jobs.... > make/Main.gmk:193: recipe for target 'java.base-java' failed ok, it means there is a bug in the compiler, the analysis done for unsafe varargs (with -Xlint:varargs) doesn't check that the called method (here Arrays.asList()) is tagged with @SafeVarargs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+10835776+stsypanov at openjdk.java.net Thu Dec 17 11:06:56 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Dec 2020 11:06:56 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 10:50:01 GMT, R?mi Forax wrote: >> Hi, without this I get failed build: >> Compiling 3057 files for java.base >> Compiling 89 properties into resource bundles for java.desktop >> >> return c.addAll(Arrays.asList(elements)); >> ^ >> error: warnings found and -Werror specified >> 1 error >> 1 warning >> make[3]: *** [/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 >> CompileJavaModules.gmk:604: recipe for target '/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch' failed >> make[2]: *** [java.base-java] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> make/Main.gmk:193: recipe for target 'java.base-java' failed > > ok, it means there is a bug in the compiler, the analysis done for unsafe varargs (with -Xlint:varargs) doesn't check that the called method (here Arrays.asList()) is tagged with @SafeVarargs. Should I then wait for the fix of that bug to remove `@SupressWarnings`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+828220+forax at openjdk.java.net Thu Dec 17 11:10:57 2020 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Dec 2020 11:10:57 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 11:03:45 GMT, ?????? ??????? wrote: >> ok, it means there is a bug in the compiler, the analysis done for unsafe varargs (with -Xlint:varargs) doesn't check that the called method (here Arrays.asList()) is tagged with @SafeVarargs. > > Should I then wait for the fix of that bug to remove `@SupressWarnings`? I don't think so, the code is fine, for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From jboes at openjdk.java.net Thu Dec 17 11:35:59 2020 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 17 Dec 2020 11:35:59 GMT Subject: [jdk16] Integrated: 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect In-Reply-To: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> References: <36cexg5xTLD6n0KaYrfEdTo5RHwCjlHEYJoVEyieDHA=.6c45a939-9c83-4073-acb3-3e17de6586fe@github.com> Message-ID: On Wed, 16 Dec 2020 15:17:57 GMT, Julia Boes wrote: > Another change to align with upcoming changes in the JLS terminology ('type' versus 'class and interface'). > > For background see: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html > > Where a class models types (as in the type of a variable or an expression), the change in terminology is mostly not applicable. For easier reviewing, paragraphs will only be reflowed before the PR is integrated. This pull request has now been integrated. Changeset: 952dc704 Author: Julia Boes URL: https://git.openjdk.java.net/jdk16/commit/952dc704 Stats: 75 lines in 14 files changed: 2 ins; 1 del; 72 mod 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk16/pull/36 From github.com+741251+turbanoff at openjdk.java.net Thu Dec 17 11:37:59 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 17 Dec 2020 11:37:59 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 10:29:50 GMT, Alan Bateman wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base >> take advantage of "flow scoping" to eliminate casts > > src/java.base/share/classes/jdk/internal/misc/Signal.java line 102: > >> 100: */ >> 101: public boolean equals(Object other) { >> 102: if (this == other) { > > It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1. Actually, I'm not sure if `oth` is better name for variable than `other1`. I would say they have the same rank :) ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From jiefu at openjdk.java.net Thu Dec 17 12:17:02 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 17 Dec 2020 12:17:02 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 Message-ID: Hi all, java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. The current implementation only supports maximum 3800M on 32-bit systems [1]. I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. The fix just skips the test for 32-bit systems. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 ------------- Commit messages: - 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 Changes: https://git.openjdk.java.net/jdk/pull/1817/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1817&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258584 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1817/head:pull/1817 PR: https://git.openjdk.java.net/jdk/pull/1817 From herrick at openjdk.java.net Thu Dec 17 12:49:58 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 17 Dec 2020 12:49:58 GMT Subject: [jdk16] RFR: 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 In-Reply-To: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> References: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> Message-ID: On Wed, 16 Dec 2020 00:24:20 GMT, Alexey Semenyuk wrote: > Ignore files created by prefs subsystem when checking if source runtime contains the same files as packed runtime. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/31 From aefimov at openjdk.java.net Thu Dec 17 13:18:59 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 17 Dec 2020 13:18:59 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > take advantage of "flow scoping" to eliminate casts Thank you for checking `HttpURLConnection` and `Socket`. The latest version looks good to me. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/20 From dfuchs at openjdk.java.net Thu Dec 17 13:34:59 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Dec 2020 13:34:59 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 11:35:26 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/jdk/internal/misc/Signal.java line 102: >> >>> 100: */ >>> 101: public boolean equals(Object other) { >>> 102: if (this == other) { >> >> It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1. > > Actually, I'm not sure if `oth` is better name for variable than `other1`. > I would say they have the same rank :) I believe Alan is suggesting to do: /** * Compares the equality of two Signal objects. * * @param obj the object to compare with. * @return whether two Signal objects are equal. */ public boolean equals(Object obj) { if (this == obj) { this leaves the variable name `other` free for later use inside the method. ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From alanb at openjdk.java.net Thu Dec 17 13:38:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Dec 2020 13:38:57 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 13:32:06 GMT, Daniel Fuchs wrote: >> Actually, I'm not sure if `oth` is better name for variable than `other1`. >> I would say they have the same rank :) > > I believe Alan is suggesting to do: > > /** > * Compares the equality of two Signal objects. > * > * @param obj the object to compare with. > * @return whether two Signal objects are equal. > */ > public boolean equals(Object obj) { > if (this == obj) { > > this leaves the variable name `other` free for later use inside the method. > Actually, I'm not sure if `oth` is better name for variable than `other1`. > I would say they have the same rank :) Sorry, I should have been clearer, the comment was about equals(Object other). If you rename "other" then it will avoid "other1" ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From christoph.langer at sap.com Thu Dec 17 13:45:00 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Dec 2020 13:45:00 +0000 Subject: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module In-Reply-To: References: Message-ID: Hi Martin, this makes sense. Thanks for doing the backport. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf Of > Doerr, Martin > Sent: Mittwoch, 16. Dezember 2020 14:39 > To: core-libs-dev ; jdk-updates- > dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8211825: > ModuleLayer.defineModulesWithXXX does not setup delegation when > module reads automatic module > > Hi, > > JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity. > The original change applies cleanly, by javac from 11u has a problem with the > new AutomaticModulesTest: > AutomaticModulesTest.java:70: error: reference to createJarFile is > ambiguous > JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES); > ^ > both method createJarFile(Path,Path,Path...) in JarUtils and method > createJarFile(Path,Path,String...) in JarUtils match > > I suggest to resolve it this way: > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.p > atch > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211825 > > Original change: > http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01 > > 11u webrev: > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.0 > 0/ > > Please review. > > Best regards, > Martin From chegar at openjdk.java.net Thu Dec 17 13:55:19 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 17 Dec 2020 13:55:19 GMT Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v5] In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com> References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com> Message-ID: > The ByteBuffers micro benchmark seems to be a little dated. > > It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. > > This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: > > 1. Remove allocation from the individual benchmarks - it just creates noise. > 2. Consolidate per-thread shared heap and direct buffers. > 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. > 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. > 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Template generation of carrier specific micro-benchmarks. * Benchmarks are now split out into carrier specific source files * All variants and views are covered * Test scenario naming is idiomatic Even with the split by carrier, regex expressions can be used to easily run subsets the benchmarks. E.g. test all memory operations related to Short with read-only buffers: $ java -jar benchmarks.jar "org.openjdk.bench.java.nio..*Buffers.testDirect.*Short.*" -l Benchmarks: org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortRO org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortSwapRO org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewRO org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewSwapRO org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewRO org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewSwapRO - Merge branch 'master' into bb-bench - Add explicitly allocated heap carrier buffer tests - Replace Single with Loop - whitespace - Add additional carrier views and endianness variants. A large number of variants are now covered. The individual benchmarks conform to the following convention: test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)? This allows to easily run a subset of particular interest. For example: Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*" Char only :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*" Bulk only :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*" Put with Int or Long carrier :- test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?" Running all variants together is likely not all that useful, since there will be a lot of data. The param sizes are changed so as to better allow for wider carrier views. There are a lot of individual benchmark methods, but their implementation is trivial, and largely mechanical. Question: where do folk stand on having a `main` method in a benchmark - as a standalone-run sanity? I found this useful to assert the validity of the benchmark code. It can be commented out if it could somehow affect the benchmark runs. ( I omitted read-only views, since they less interesting, and we already have a lot of variants ) - Initial changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1430/files - new: https://git.openjdk.java.net/jdk/pull/1430/files/5ee5d8bf..a8e81a84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=03-04 Stats: 46605 lines in 988 files changed: 29018 ins; 8180 del; 9407 mod Patch: https://git.openjdk.java.net/jdk/pull/1430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430 PR: https://git.openjdk.java.net/jdk/pull/1430 From github.com+741251+turbanoff at openjdk.java.net Thu Dec 17 14:01:14 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 17 Dec 2020 14:01:14 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v5] In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/20/files - new: https://git.openjdk.java.net/jdk/pull/20/files/f5727ca9..314217ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From dfuchs at openjdk.java.net Thu Dec 17 14:22:04 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Dec 2020 14:22:04 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v5] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: <2d3umOCXurFwL9NlMzsBZbyN9U2o1p2VUisHHPzfaxU=.71d60783-f578-4111-a250-3b9820fc8d5a@github.com> On Thu, 17 Dec 2020 14:01:14 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base src/java.base/share/classes/jdk/internal/misc/Signal.java line 101: > 99: * @return whether two Signal objects are equal. > 100: */ > 101: public boolean equals(Object oth) { I'd suggest to replace `oth` with `obj` and fix the `@param` clause in the method javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From simon at dancingcloudservices.com Thu Dec 17 14:34:29 2020 From: simon at dancingcloudservices.com (Simon Roberts) Date: Thu, 17 Dec 2020 07:34:29 -0700 Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: When updating this, might you take the opportunity to remove the ambiguous antecedent too? The use of "this method" when there are two methods in the discussion (Collections.addAll, and the proximate one; Collection.addAll) is unclear (indeed, one could argue the original text might have intended to use "this method" to refer to Collection.addAll, in which interpretation it's correct :) A more specific comment on the lines of "Collection.addAll is likely to run faster..." would entirely avoid the ambiguity. Perhaps that's the intended solution anyway, in which case, I apologize for the distraction. On Thu, Dec 17, 2020 at 3:38 AM R?mi Forax wrote: > On Thu, 17 Dec 2020 10:15:23 GMT, ?????? ??????? 10835776+stsypanov at openjdk.org> wrote: > > >> Hello, I feel like this was previously discussed in > https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot > find original mail I post this here. > >> > >> Currently `Collections.addAll()` is implemented and documented as: > >> /** > >> * ... > >> * The behavior of this convenience method is identical to that of > >> * {@code c.addAll(Arrays.asList(elements))}, but this method is > likely > >> * to run significantly faster under most implementations. > >> */ > >> @SafeVarargs > >> public static boolean addAll(Collection c, T... > elements) { > >> boolean result = false; > >> for (T element : elements) > >> result |= c.add(element); > >> return result; > >> } > >> > >> But it practice the notation `this method is likely to run > significantly faster under most implementations` is completely wrong. When > I take this [benchmark]( > https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) > and run it on JDK 14 I get the following results: > >> (collection) > (size) Score Error Units > >> addAll ArrayList > 10 37.9 ? 1.9 ns/op > >> addAll ArrayList > 100 83.8 ? 3.4 ns/op > >> addAll ArrayList > 1000 678.2 ? 23.0 ns/op > >> collectionsAddAll ArrayList > 10 50.9 ? 1.1 ns/op > >> collectionsAddAll ArrayList > 100 751.4 ? 47.4 ns/op > >> collectionsAddAll ArrayList > 1000 8839.8 ? 710.7 ns/op > >> > >> addAll HashSet > 10 128.4 ? 5.9 ns/op > >> addAll HashSet > 100 1864.2 ? 102.4 ns/op > >> addAll HashSet > 1000 16615.5 ? 1202.6 ns/op > >> collectionsAddAll HashSet > 10 172.8 ? 6.0 ns/op > >> collectionsAddAll HashSet > 100 2355.8 ? 195.4 ns/op > >> collectionsAddAll HashSet > 1000 20364.7 ? 1164.0 ns/op > >> > >> addAll ArrayDeque > 10 54.0 ? 0.4 ns/op > >> addAll ArrayDeque > 100 319.7 ? 2.5 ns/op > >> addAll ArrayDeque > 1000 3176.9 ? 22.2 ns/op > >> collectionsAddAll ArrayDeque > 10 66.5 ? 1.4 ns/op > >> collectionsAddAll ArrayDeque > 100 808.1 ? 55.9 ns/op > >> collectionsAddAll ArrayDeque > 1000 5639.6 ? 240.9 ns/op > >> > >> addAll CopyOnWriteArrayList > 10 18.0 ? 0.7 ns/op > >> addAll CopyOnWriteArrayList > 100 39.4 ? 1.7 ns/op > >> addAll CopyOnWriteArrayList > 1000 371.1 ? 17.0 ns/op > >> collectionsAddAll CopyOnWriteArrayList > 10 251.9 ? 18.4 ns/op > >> collectionsAddAll CopyOnWriteArrayList > 100 3405.9 ? 304.8 ns/op > >> collectionsAddAll CopyOnWriteArrayList > 1000 247496.8 ? 23502.3 ns/op > >> > >> addAll ConcurrentLinkedDeque > 10 81.4 ? 2.8 ns/op > >> addAll ConcurrentLinkedDeque > 100 609.1 ? 26.4 ns/op > >> addAll ConcurrentLinkedDeque > 1000 4494.5 ? 219.3 ns/op > >> collectionsAddAll ConcurrentLinkedDeque > 10 189.8 ? 2.5 ns/op > >> collectionsAddAll ConcurrentLinkedDeque > 100 1660.0 ? 62.0 ns/op > >> collectionsAddAll ConcurrentLinkedDeque > 1000 17649.2 ? 300.9 ns/op > >> > >> addAll:?gc.alloc.rate.norm ArrayList > 10 160.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm ArrayList > 100 880.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm ArrayList > 1000 8080.3 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ArrayList > 10 80.0 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ArrayList > 100 1400.2 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ArrayList > 1000 15025.6 ? 0.1 B/op > >> > >> addAll:?gc.alloc.rate.norm HashSet > 10 464.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm HashSet > 100 5328.5 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm HashSet > 1000 48516.7 ? 0.1 B/op > >> collectionsAddAll:?gc.alloc.rate.norm HashSet > 10 464.0 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm HashSet > 100 5328.5 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm HashSet > 1000 48516.6 ? 0.1 B/op > >> > >> addAll:?gc.alloc.rate.norm ArrayDeque > 10 112.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm ArrayDeque > 100 560.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm ArrayDeque > 1000 4160.5 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque > 10 112.0 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque > 100 1048.1 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque > 1000 14929.4 ? 0.0 B/op > >> > >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList > 10 88.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList > 100 448.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList > 1000 4048.1 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList > 10 456.0 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList > 100 22057.2 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList > 1000 2020150.3 ? 7.3 B/op > >> > >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque > 10 312.0 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque > 100 2472.1 ? 0.0 B/op > >> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque > 1000 24073.7 ? 0.1 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque > 10 288.0 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque > 100 2448.3 ? 0.0 B/op > >> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque > 1000 24051.4 ? 0.3 B/op > >> There's never a case when `Collections.addAll` is fater - on the > contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially > to dramatic difference for array-based collection. > >> > >> So I propose to reimplement the method by simply delegating to > `Arrays.asList` because the spec declares identical behaviour and to remove > perfomance notation from JavaDoc. > > > > Looks like I've found the original ticket: > https://bugs.openjdk.java.net/browse/JDK-8193031 > > Apart from the @SuppressWarnings, this looks good to me. > And i like the irony of this. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1764 > -- Simon Roberts (303) 249 3613 From dfuchs at openjdk.java.net Thu Dec 17 14:57:05 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Dec 2020 14:57:05 GMT Subject: RFR: 8258582: HttpClient: the HttpClient doesn't explicitely shutdown its default executor when stopping. Message-ID: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> Hi, Please find an almost trivial fix for: 8258582: HttpClient: the HttpClient doesn't explicitely shutdown its default executor when stopping. The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself. best regards, -- daniel ------------- Commit messages: - 8258582: HttpClient: the HttpClient doesn't explicitely shutdown its default executor when stopping. Changes: https://git.openjdk.java.net/jdk/pull/1822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258582 Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1822/head:pull/1822 PR: https://git.openjdk.java.net/jdk/pull/1822 From asemenyuk at openjdk.java.net Thu Dec 17 15:36:01 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Dec 2020 15:36:01 GMT Subject: [jdk16] Integrated: 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 In-Reply-To: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> References: <6GlK3t3gpe_-0UGZTyv5LpK9qm7uFXF7HswWLmIXb7g=.ebac9f1c-485d-445b-9811-eafe8489e296@github.com> Message-ID: <1T6tLZ5ZWPRkvdKoJjjX40be94NPes7_O_8iOYwlX9Q=.a3040f42-48af-4199-9725-d7f8b3aff169@github.com> On Wed, 16 Dec 2020 00:24:20 GMT, Alexey Semenyuk wrote: > Ignore files created by prefs subsystem when checking if source runtime contains the same files as packed runtime. This pull request has now been integrated. Changeset: 61cbf0ff Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk16/commit/61cbf0ff Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 Reviewed-by: almatvee, herrick ------------- PR: https://git.openjdk.java.net/jdk16/pull/31 From martin.doerr at sap.com Thu Dec 17 15:50:55 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 17 Dec 2020 15:50:55 +0000 Subject: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review! Best regards, Martin > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 17. Dezember 2020 14:45 > To: Doerr, Martin ; core-libs-dev dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does > not setup delegation when module reads automatic module > > Hi Martin, > > this makes sense. Thanks for doing the backport. > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev On Behalf Of > > Doerr, Martin > > Sent: Mittwoch, 16. Dezember 2020 14:39 > > To: core-libs-dev ; jdk-updates- > > dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8211825: > > ModuleLayer.defineModulesWithXXX does not setup delegation when > > module reads automatic module > > > > Hi, > > > > JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity. > > The original change applies cleanly, by javac from 11u has a problem with > the > > new AutomaticModulesTest: > > AutomaticModulesTest.java:70: error: reference to createJarFile is > > ambiguous > > JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES); > > ^ > > both method createJarFile(Path,Path,Path...) in JarUtils and method > > createJarFile(Path,Path,String...) in JarUtils match > > > > I suggest to resolve it this way: > > > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.p > > atch > > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8211825 > > > > Original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01 > > > > 11u webrev: > > > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.0 > > 0/ > > > > Please review. > > > > Best regards, > > Martin From rriggs at openjdk.java.net Thu Dec 17 16:18:02 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Dec 2020 16:18:02 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 12:11:33 GMT, Jie Fu wrote: > Hi all, > > java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implementation only supports maximum 3800M on 32-bit systems [1]. > > I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. > So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. > The fix just skips the test for 32-bit systems. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 Disabling all of the tests on 32 bit is not a good idea. Instead the HexFormatTest.testOOME test should be skipped or the OOME should be ignored. Checking Runtime.getRuntime().maxMemory() should provide enough info to skip it. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1817 From github.com+34924738+mahendrachhipa at openjdk.java.net Thu Dec 17 16:24:10 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Thu, 17 Dec 2020 16:24:10 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v5] In-Reply-To: References: Message-ID: > jaxp.library.SimpleHttpServer > https://bugs.openjdk.java.net/browse/JDK-8212035 Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Implemented the Review comments. - Implemented the review comments - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035 - Implemnted the review comments. - Implemnted the review comments. - Implemented the review comments. - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer https://bugs.openjdk.java.net/browse/JDK-8212035 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1632/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=04 Stats: 650 lines in 17 files changed: 226 ins; 321 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/1632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632 PR: https://git.openjdk.java.net/jdk/pull/1632 From github.com+34924738+mahendrachhipa at openjdk.java.net Thu Dec 17 16:24:11 2020 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Thu, 17 Dec 2020 16:24:11 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v4] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:44:59 GMT, Daniel Fuchs wrote: >> Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035 >> - Implemnted the review comments. > > test/lib/jdk/test/lib/net/SimpleHttpServer.java line 105: > >> 103: Path fPath; >> 104: try { >> 105: fPath = Paths.get(docRoot, path); > > Hi Mahendra, > > I am not comfortable with this. You cannot just concatenate a file system path with a URI path in the general case (think windows file system). I would suggest to transform docRoot into a root URI using `Path.of(docRoot).toURI().normalize()` - then you can probably concatenate the string representation of this root URI with the *raw path* extracted from the request URI, normalize that again (to remove potential double slashes) and convert that back into a Path using Path.of(URI). > Some additional conditions might need to be asserted: > - `t.getRequestURI().getRawPath()` should either be empty or start with `"/"` (and even that may be a bit lax) > - the resulting URI you obtain (after normalization and before converting back to Path) should either be equal to the root URI or start with the root URI. > `(rootURI.toString().equals(uri.toString()) || uri.toString().startsWith(rootUri.toString() + "/") )` > > best regards, > > -- daniel Thanks Daniel. I have implemented the review comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From bpb at openjdk.java.net Thu Dec 17 16:33:03 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Dec 2020 16:33:03 GMT Subject: Integrated: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:22:06 GMT, Brian Burkhalter wrote: > Please review this small verbiage change to specify clearly the behavior of `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. This pull request has now been integrated. Changeset: 143998e4 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/143998e4 Stats: 95 lines in 2 files changed: 95 ins; 0 del; 0 mod 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array Reviewed-by: naoto, smarks, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/1737 From chegar at openjdk.java.net Thu Dec 17 16:34:57 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 17 Dec 2020 16:34:57 GMT Subject: RFR: 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. In-Reply-To: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> References: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> Message-ID: <-42zDyZeRKIT4P4Ut3JaTRkZnPngH7b91YS8EVl8kKU=.0e579ae7-9e9c-4f39-8731-db6c5d417847@github.com> On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote: > Hi, > > Please find an almost trivial fix for: > 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. > > The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself. > > best regards, > > -- daniel Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1822 From jjg at openjdk.java.net Thu Dec 17 16:39:17 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 17 Dec 2020 16:39:17 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v3] In-Reply-To: References: Message-ID: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Address review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/16/files - new: https://git.openjdk.java.net/jdk16/pull/16/files/ec111185..1a406f35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk16/pull/16 From github.com+7693005+jarviscraft at openjdk.java.net Thu Dec 17 17:03:07 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Thu, 17 Dec 2020 17:03:07 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached Message-ID: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. ------------- Commit messages: - 8258588: MD5 MessageDigest in java.util.UUID should be cached Changes: https://git.openjdk.java.net/jdk/pull/1821/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258588 Stats: 33 lines in 1 file changed: 26 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821 PR: https://git.openjdk.java.net/jdk/pull/1821 From hannesw at openjdk.java.net Thu Dec 17 17:06:00 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 17 Dec 2020 17:06:00 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v3] In-Reply-To: References: Message-ID: <-H-OPr6wCQeLESYlsa7aQTVJjtzxeknaqJRpy0-s0L8=.af6de1b0-749d-4cf4-898b-2f4284db3ebd@github.com> On Thu, 17 Dec 2020 16:39:17 GMT, Jonathan Gibbons wrote: >> This is for JDK16, as a precursor to fixing JDK-8258002. >> >> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. >> >> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40: > 38: var MIN_RESULTS = 3; > 39: var MAX_RESULTS = 500; > 40: var UNNAMED = ">"; Oops, an additional closing angle bracket slipped there. ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From naoto at openjdk.java.net Thu Dec 17 17:07:02 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Dec 2020 17:07:02 GMT Subject: [jdk16] RFR: 8258259: Unicode linebreak matching behavior is incorrect; backout JDK-8235812 In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 01:01:38 GMT, Stuart Marks wrote: > Back out code changes from JDK-8235812 to restore correct matching behavior. Adjust test to comment out cases that tested for incorrect behavior. Backout and test changes according to it look good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/40 From hannesw at openjdk.java.net Thu Dec 17 17:13:15 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 17 Dec 2020 17:13:15 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v4] In-Reply-To: References: Message-ID: <6teL5P5Sg13pNY0zUuTF-wQc5a_rr8zrq4xNAxoGJL0=.5d6444e0-66d4-43ee-aa80-5ac2bfa9fc75@github.com> On Thu, 17 Dec 2020 17:10:10 GMT, Jonathan Gibbons wrote: >> This is for JDK16, as a precursor to fixing JDK-8258002. >> >> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. >> >> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment Marked as reviewed by hannesw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From jjg at openjdk.java.net Thu Dec 17 17:13:14 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 17 Dec 2020 17:13:14 GMT Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v4] In-Reply-To: References: Message-ID: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Address review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/16/files - new: https://git.openjdk.java.net/jdk16/pull/16/files/1a406f35..de6802c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk16/pull/16 From dfuchs at openjdk.java.net Thu Dec 17 17:15:03 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Dec 2020 17:15:03 GMT Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer [v5] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 16:24:10 GMT, Mahendra Chhipa wrote: >> jaxp.library.SimpleHttpServer >> https://bugs.openjdk.java.net/browse/JDK-8212035 > > Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Implemented the Review comments. > - Implemented the review comments > - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035 > - Implemnted the review comments. > - Implemnted the review comments. > - Implemented the review comments. > - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with > jaxp.library.SimpleHttpServer > https://bugs.openjdk.java.net/browse/JDK-8212035 test/lib/jdk/test/lib/net/SimpleHttpServer.java line 104: > 102: try { > 103: uri = URI.create(rootUri.getRawPath() + path).normalize(); > 104: fPath = Path.of(uri.getRawPath()); This is wrong. It should be `fpath = Path.of(uri);`. See https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/nio/file/Path.html#of(java.net.URI) ------------- PR: https://git.openjdk.java.net/jdk/pull/1632 From lancea at openjdk.java.net Thu Dec 17 17:20:56 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Dec 2020 17:20:56 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com> References: <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com> Message-ID: On Wed, 16 Dec 2020 14:42:36 GMT, Richard Fussenegger wrote: > > There is very little value in adding the exception doing so might prevent existing applications from continuing to function. > > I disagree on the value and am with the author of the original issue. All these existing applications are functioning but factually invalid, adding the exception like we have it in all other methods of the class would surface the issue in exactly those applications. While I can appreciate that the current behavior might be less than ideal, changing it to throw an UnsupportedOperationException could break existing applications. Have you had a chance to research the number of uses of version() in the java eco-system to determine that the risk to existing applications will minimal? If you feel that the change in functionality is important for users of UUID, then please propose a replacement method for version and propose to deprecate the existing method ? If you decide to move forward with proposing a replacement method for version, then please socialize the proposal on corelibs-dev prior to creating a new PR. Please note that a CSR will also be required to move forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From paul.sandoz at oracle.com Thu Dec 17 17:31:49 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Dec 2020 09:31:49 -0800 Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > On Dec 16, 2020, at 1:47 AM, Chris Hegarty wrote: > > On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov wrote: > >>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base >> >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base >> use instanceof pattern matching in UnixPath too > > Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow. > > src/java.base/share/classes/java/net/InetSocketAddress.java line 414: > >> 412: if (!(obj instanceof InetSocketAddress)) >> 413: return false; >> 414: return holder.equals(((InetSocketAddress) obj).holder); > > If we restructure this a little we can get: > > public final boolean equals(Object obj) { > if (obj instanceof InetSocketAddress that) > return holder.equals(that.holder); > return false; > } > It?s also possible to use a ternary expression as in: return (obj instanceof InetSocketAddress that) ? holder.equals(that.holder) : false; Not suggesting you have to do that here. More for information purposes for those that might not know. Paul. From github.com+741251+turbanoff at openjdk.java.net Thu Dec 17 17:43:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 17 Dec 2020 17:43:10 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v6] In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base rename 'other' -> 'oth', 'other1' -> 'other' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/20/files - new: https://git.openjdk.java.net/jdk/pull/20/files/314217ec..fe303a2c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From github.com+741251+turbanoff at openjdk.java.net Thu Dec 17 17:47:12 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 17 Dec 2020 17:47:12 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v7] In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base rename 'oth' -> 'obj' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/20/files - new: https://git.openjdk.java.net/jdk/pull/20/files/fe303a2c..5949f9a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk/pull/20 From michaelm at openjdk.java.net Thu Dec 17 18:01:59 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 17 Dec 2020 18:01:59 GMT Subject: RFR: 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. In-Reply-To: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> References: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> Message-ID: On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote: > Hi, > > Please find an almost trivial fix for: > 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. > > The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself. > > best regards, > > -- daniel Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1822 From jjg at openjdk.java.net Thu Dec 17 18:36:58 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 17 Dec 2020 18:36:58 GMT Subject: [jdk16] Integrated: JDK-8247994: Localize javadoc search In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. This pull request has now been integrated. Changeset: 30ca0a5d Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk16/commit/30ca0a5d Stats: 120 lines in 9 files changed: 87 ins; 6 del; 27 mod 8247994: Localize javadoc search Reviewed-by: hannesw, ihse ------------- PR: https://git.openjdk.java.net/jdk16/pull/16 From jwilhelm at openjdk.java.net Thu Dec 17 20:44:15 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Dec 2020 20:44:15 GMT Subject: Integrated: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8247994: Localize javadoc search - 8258515: javac should issue an error if an annotation is nested in a local class or interface - 8258225: compiler/c2/cr6340864/TestIntVect.java runs faster in interpreter - 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2 - 8257621: JFR StringPool misses cached items across consecutive recordings - 8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region - 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect - 8258505: [TESTBUG] TestDivZeroWithSplitIf.java fails due to missing UnlockDiagnosticVMOptions - 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1827&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1827&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1827/files Stats: 773 lines in 63 files changed: 449 ins; 124 del; 200 mod Patch: https://git.openjdk.java.net/jdk/pull/1827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1827/head:pull/1827 PR: https://git.openjdk.java.net/jdk/pull/1827 From jwilhelm at openjdk.java.net Thu Dec 17 20:44:15 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Dec 2020 20:44:15 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 20:38:45 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: f15528eb Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/f15528eb Stats: 773 lines in 63 files changed: 449 ins; 124 del; 200 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1827 From herrick at openjdk.java.net Thu Dec 17 20:58:09 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 17 Dec 2020 20:58:09 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances Message-ID: Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider. ------------- Commit messages: - JDK-8223322: Improve concurrency in jpackage instances - JDK-8223322: Improve concurrency in jpackage instances Changes: https://git.openjdk.java.net/jdk/pull/1829/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1829&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223322 Stats: 214 lines in 8 files changed: 134 ins; 52 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1829/head:pull/1829 PR: https://git.openjdk.java.net/jdk/pull/1829 From github.com+7693005+jarviscraft at openjdk.java.net Thu Dec 17 21:17:10 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Thu, 17 Dec 2020 21:17:10 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached [v2] In-Reply-To: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: > Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. PROgrm_JARvis has updated the pull request incrementally with one additional commit since the last revision: 8258588: add missing " UUIDs" to comment of UUID$Md5Digest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1821/files - new: https://git.openjdk.java.net/jdk/pull/1821/files/73eb2c4f..37db4c56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821 PR: https://git.openjdk.java.net/jdk/pull/1821 From info at j-kuhn.de Thu Dec 17 22:07:07 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Thu, 17 Dec 2020 23:07:07 +0100 Subject: JDK-8229959/JDK-8242888 Prototype for j.l.r.Proxy with hidden classes & class data Message-ID: <980818d6-32cb-47fa-4677-624ff398ca49@j-kuhn.de> Now that class data support for hidden classes in master, I decided to tackle JDK-8229959 again. JDK-8229959: Convert proxy class to use constant dynamic [1] JDK-8242888: Convert dynamic proxy to hidden classes [2] The idea is simple: Define proxies as hidden classes, pass the methods as class data, and access it from the Proxy with the MethodHandles.classDataAt() BSM. The current prototype[3] works - and aside from one test for jshell that expects a stack trace element containing "jdk.proxy" as a stack trace element (hidden classes, duh), no new tests did fail with "make test-tier1". Also, the aot tests fail ("link.exe not found"), if someone has some instructions how to get them properly run on windows, I'm very interested. But they are not new failures. Problems I did run into: I need a lookup for a class in a package to define a hidden class. --------------------------- Solution: I inject an anchor class, obtain a lookup on it, and use that. The anchor is reused for the same package, and named pkg + ".$ProxyAnchor". I need to return both the class data & created bytecode back to Proxy from ProxyGenerator --------------------------- Solution: Added a record-like class that contains both bytecode as well as the class data. Serialization of proxies did break. --------------------------- Serializing the proxy descriptor was not a problem - the problem is how the constructor for serialization works. It spins a MagicConstructorAccessor subclass - which requires for the created class to have a binary name. Hidden classes don't have one. Solution: MethodHandles don't have this limitation, so I hacked a shared secret into JavaLangInvokeAccess to create such a MethodHandle, and replaced the Reflection.generateConstructor() implementation to use a ConstructorAccessor that delegates to that MethodHandle. --------------------------- In all, this is a prototype - for now, I want some feedback on the approach. Also a broader view - making it work is one thing. Checking all the right boxes in all the different areas an other. Some parts might still be a bit sloppy, but I want to know if there is merit if I follow the current path and polish it up. - Johannes PS.: I decided to use a draft PR - as with my last approaches I had problems when I did commit more stuff. [1]: https://bugs.openjdk.java.net/browse/JDK-8229959 [2]: https://bugs.openjdk.java.net/browse/JDK-8242888 [3]: https://github.com/openjdk/jdk/pull/1830/files From github.com+1059453+fleshgrinder at openjdk.java.net Thu Dec 17 22:11:57 2020 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Thu, 17 Dec 2020 22:11:57 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com> Message-ID: On Thu, 17 Dec 2020 17:18:37 GMT, Lance Andersen wrote: >>> There is very little value in adding the exception doing so might prevent existing applications from continuing to function. >> >> I disagree on the value and am with the author of the original issue. All these existing applications are functioning but factually invalid, adding the exception like we have it in all other methods of the class would surface the issue in exactly those applications. > >> > There is very little value in adding the exception doing so might prevent existing applications from continuing to function. >> >> I disagree on the value and am with the author of the original issue. All these existing applications are functioning but factually invalid, adding the exception like we have it in all other methods of the class would surface the issue in exactly those applications. > > While I can appreciate that the current behavior might be less than ideal, changing it to throw an UnsupportedOperationException could break existing applications. Have you had a chance to research the number of uses of version() in the java eco-system to determine that the risk to existing applications will minimal? > > If you feel that the change in functionality is important for users of UUID, then please propose a replacement method for version and propose to deprecate the existing method ? > > If you decide to move forward with proposing a replacement method for version, then please socialize the proposal on corelibs-dev prior to creating a new PR. > > Please note that a CSR will also be required to move forward. I cannot create CSRs, only members can. Deprecating and switching to another function results in much more work for users overall because it affects all those who use it correctly as well. In other words: 100% I'm in favor of rejection if that's the way forward. What's wrong with creating PRs for existing issues? I thought that more contributions is actually the reason OpenJDK came to GitHub. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From rriggs at openjdk.java.net Thu Dec 17 22:18:55 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Dec 2020 22:18:55 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com> Message-ID: On Thu, 17 Dec 2020 22:07:36 GMT, Richard Fussenegger wrote: >>> > There is very little value in adding the exception doing so might prevent existing applications from continuing to function. >>> >>> I disagree on the value and am with the author of the original issue. All these existing applications are functioning but factually invalid, adding the exception like we have it in all other methods of the class would surface the issue in exactly those applications. >> >> While I can appreciate that the current behavior might be less than ideal, changing it to throw an UnsupportedOperationException could break existing applications. Have you had a chance to research the number of uses of version() in the java eco-system to determine that the risk to existing applications will minimal? >> >> If you feel that the change in functionality is important for users of UUID, then please propose a replacement method for version and propose to deprecate the existing method ? >> >> If you decide to move forward with proposing a replacement method for version, then please socialize the proposal on corelibs-dev prior to creating a new PR. >> >> Please note that a CSR will also be required to move forward. > > I cannot create CSRs, only members can. Deprecating and switching to another function results in much more work for users overall because it affects all those who use it correctly as well. In other words: 100% > > I'm in favor of rejection if that's the way forward. > > What's wrong with creating PRs for existing issues? I thought that more contributions is actually the reason OpenJDK came to GitHub. ?? Often an enhancement is created when there's an idea of an improvement but no resources to do the research and develop a justification. That work has to be done when someone has time. Usually ideas are discussed on one of the many OpenJDK email aliases to validate the idea and the approach before developing the code. See the list of OpenJDK Mail lists for details. https://mail.openjdk.java.net/mailman/listinfo As for moving to GitHub, it was in part to make it easier to collaborate on the development but also to move from Mercurial to Git. But GitHub does not replace the need for discussion on the Email Lists. ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From dfuchs at openjdk.java.net Thu Dec 17 22:36:55 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Dec 2020 22:36:55 GMT Subject: Integrated: 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. In-Reply-To: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> References: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com> Message-ID: On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs wrote: > Hi, > > Please find an almost trivial fix for: > 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. > > The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself. > > best regards, > > -- daniel This pull request has now been integrated. Changeset: 3f77a600 Author: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/3f77a600 Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping. Reviewed-by: chegar, michaelm ------------- PR: https://git.openjdk.java.net/jdk/pull/1822 From mandy.chung at oracle.com Thu Dec 17 23:01:15 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2020 15:01:15 -0800 Subject: JDK-8229959/JDK-8242888 Prototype for j.l.r.Proxy with hidden classes & class data In-Reply-To: <980818d6-32cb-47fa-4677-624ff398ca49@j-kuhn.de> References: <980818d6-32cb-47fa-4677-624ff398ca49@j-kuhn.de> Message-ID: Hi Johannes, I'm glad to see this prototype.? Converting dynamic proxy to hidden classes has a few challenges as JDK-8242888 describes. 1) the serialization specification w.r.t. dynamic proxies We need to look into the implication to the specification and whether the default serialization mechanism should (or should not) support dynamic proxies if it's defined as hidden classes. 2) how to get a Lookup on a package for the dynamic proxy class to be injected in without injecting a shim class (i.e. your anchor class)? Frameworks don't always have the access to inject a class in a package defined to a class loader.? Dynamic proxies are a use case to determine what functionality is needed to avoid spinning a shim class. 3) protection domain The current spec of Proxy class is defined with null protection domain (same protection domain as the bootstrap class loader). Lookup::defineHiddenClass defines the hidden class in the same protection domain as the defining class loader.? This requires to understand deeper the compatibility risks and what and how applications/libraries depend on this behavior. That's all the feedbacks I can share so far.? We need to have a clear idea w.r.t. serialization spec and compatibility risk to existing code w.r.t. protection domain and explore other options. W.r.t. AOT tests, AOT has been disabled in openjdk build [1] and that may be the reason why these tests fail. Mandy [1] https://github.com/openjdk/jdk/pull/960 On 12/17/20 2:07 PM, Johannes Kuhn wrote: > Now that class data support for hidden classes in master, I decided to > tackle JDK-8229959 again. > > JDK-8229959: Convert proxy class to use constant dynamic [1] > JDK-8242888: Convert dynamic proxy to hidden classes [2] > > The idea is simple: Define proxies as hidden classes, pass the methods > as class data, and access it from the Proxy with the > MethodHandles.classDataAt() BSM. > > The current prototype[3] works - and aside from one test for jshell > that expects a stack trace element containing "jdk.proxy" as a stack > trace element (hidden classes, duh), no new tests did fail with "make > test-tier1". > Also, the aot tests fail ("link.exe not found"), if someone has some > instructions how to get them properly run on windows, I'm very > interested. But they are not new failures. > > Problems I did run into: > > I need a lookup for a class in a package to define a hidden class. > --------------------------- > Solution: I inject an anchor class, obtain a lookup on it, and use > that. The anchor is reused for the same package, and named pkg + > ".$ProxyAnchor". > > I need to return both the class data & created bytecode back to Proxy > from ProxyGenerator > --------------------------- > Solution: Added a record-like class that contains both bytecode as > well as the class data. > > Serialization of proxies did break. > --------------------------- > Serializing the proxy descriptor was not a problem - the problem is > how the constructor for serialization works. > It spins a MagicConstructorAccessor subclass - which requires for the > created class to have a binary name. Hidden classes don't have one. > Solution: MethodHandles don't have this limitation, so I hacked a > shared secret into JavaLangInvokeAccess to create such a MethodHandle, > and replaced the Reflection.generateConstructor() implementation to > use a ConstructorAccessor that delegates to that MethodHandle. > > --------------------------- > > In all, this is a prototype - for now, I want some feedback on the > approach. Also a broader view - making it work is one thing. > Checking all the right boxes in all the different areas an other. > Some parts might still be a bit sloppy, but I want to know if there is > merit if I follow the current path and polish it up. > > - Johannes > > PS.: I decided to use a draft PR - as with my last approaches I had > problems when I did commit more stuff. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8229959 > [2]: https://bugs.openjdk.java.net/browse/JDK-8242888 > [3]: https://github.com/openjdk/jdk/pull/1830/files > From almatvee at openjdk.java.net Thu Dec 17 23:22:56 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 17 Dec 2020 23:22:56 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: Message-ID: <80p8b-7uRxps4m7SOfxovoYpyOI46KKbCs1Gnd5hbKU=.c4eb28aa-b82a-46e8-b265-52adedb434a0@github.com> On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick wrote: > Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider. Changes looks fine, but are we sure that external 3rd party tools used by jpackage will work concurrently without any issues? ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From asemenyuk at openjdk.java.net Thu Dec 17 23:26:56 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Dec 2020 23:26:56 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: Message-ID: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick wrote: > Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider. Changes requested by asemenyuk (Committer). test/jdk/tools/jpackage/share/ConcurrentTest.java line 53: > 51: JPackageCommand.helloAppImage("com.other/com.other.Hello") > 52: .useToolProvider(true) > 53: .setPackageType(PackageType.getDefault()) `.removeArgumentWithValue("--type")` can be used to make jpackage create default native package. This will eliminate need to introduce `packageType.getDefault()` method. However, I'd rather replace JPackageCommand with PackageTest in this test scenario. Something like this: final PackageTest cmd1 = new PackageTest() .configureHelloApp() .addInitializer(cmd -> { cmd.setArgumentValue("--name", "ConcurrentOtherInstaller"); }); `cmd1.run(PackageTest.Action.CREATE);` would result in a package creation but will no unpack or install will be attempted. PackageTest is better as it will run tests on created package making sure it is valid. ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From asemenyuk at openjdk.java.net Thu Dec 17 23:33:01 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Dec 2020 23:33:01 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 20:46:50 GMT, Andy Herrick wrote: > Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider. test/jdk/tools/jpackage/share/ConcurrentTest.java line 68: > 66: > 67: cmd1.useToolProvider(false); > 68: cmd1.useToolProvider(false); Shouldn't this be `cmd2`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From asemenyuk at openjdk.java.net Thu Dec 17 23:33:00 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Dec 2020 23:33:00 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> References: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> Message-ID: On Thu, 17 Dec 2020 23:24:02 GMT, Alexey Semenyuk wrote: >> Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider. > > Changes requested by asemenyuk (Committer). I'd propose to update the test to run more that two concurrent instance of jpackage command. > test/jdk/tools/jpackage/share/ConcurrentTest.java line 68: > >> 66: >> 67: cmd1.useToolProvider(false); >> 68: cmd1.useToolProvider(false); > > Shouldn't this be `cmd2`? I'd parametrize the test function with `useToolProvider` parameter. This will help to avoid copy/paste of `TKit.assertTrue(times...)` ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From smarks at openjdk.java.net Fri Dec 18 00:39:58 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Dec 2020 00:39:58 GMT Subject: [jdk16] Integrated: 8258259: Unicode linebreak matching behavior is incorrect; backout JDK-8235812 In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 01:01:38 GMT, Stuart Marks wrote: > Back out code changes from JDK-8235812 to restore correct matching behavior. Adjust test to comment out cases that tested for incorrect behavior. This pull request has now been integrated. Changeset: cbc3feeb Author: Stuart Marks URL: https://git.openjdk.java.net/jdk16/commit/cbc3feeb Stats: 85 lines in 2 files changed: 8 ins; 56 del; 21 mod 8258259: Unicode linebreak matching behavior is incorrect; backout JDK-8235812 Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk16/pull/40 From info at j-kuhn.de Fri Dec 18 00:59:54 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 18 Dec 2020 01:59:54 +0100 Subject: JDK-8229959/JDK-8242888 Prototype for j.l.r.Proxy with hidden classes & class data In-Reply-To: References: <980818d6-32cb-47fa-4677-624ff398ca49@j-kuhn.de> Message-ID: Thanks Mandy, Appreciate your feedback, as always. On 18-Dec-20 0:01, Mandy Chung wrote: > Hi Johannes, > > I'm glad to see this prototype.? Converting dynamic proxy to hidden > classes has a few challenges as JDK-8242888 describes. > > 1) the serialization specification w.r.t. dynamic proxies Serialization is a must have, because annotation are implemented using dynamic proxies. But I made it work in my prototype. The serialization format uses a special PROXYCLASSDESC - basically an array of CLASSDESC of all implemented interfaces of the dynamic proxy. It then asks j.l.r.Proxy for the proxy class that implements those interfaces. The issue I run in was the way the proxy class is instantiated. ReflectionFactory::newConstructorForSerialization did spin a class that referenced the expected type by it's binary name. To avoid that, I created a MethodHandleConstructorAccessor, that just delegates call to a MethodHandle. j.l.invoke internals are very powerful and can do such shenanigans. In the end, I think no specification change is necessary, at least for that part. (Other parts may need one - the jshell test shows that such a change is visible in the stack trace) > We need to look into the implication to the specification and whether > the default serialization mechanism should (or should not) support > dynamic proxies if it's defined as hidden classes. > > 2) how to get a Lookup on a package for the dynamic proxy class to be > injected in without injecting a shim class (i.e. your anchor class)? > > Frameworks don't always have the access to inject a class in a package > defined to a class loader.? Dynamic proxies are a use case to determine > what functionality is needed to avoid spinning a shim class. That topic certainly needs a lot more thought. What are the requirements, what kind of frameworks exist, what do they need... For the dynamic proxy case: it just needs two unique packages per ClassLoader. Names don't matter, as long as they don't clash with anything else. Currently they don't clash, because the specification says: don't name your packages this way. But a hidden class (and Lookup.defineClass) will always have package private access to your package. This may or may not be intended by a framework - especially if it compiles user code, like xerces or clojure. > > 3) protection domain > > The current spec of Proxy class is defined with null protection domain > (same protection domain as the bootstrap class loader). > Lookup::defineHiddenClass defines the hidden class in the same > protection domain as the defining class loader.? This requires to > understand deeper the compatibility risks and what and how > applications/libraries depend on this behavior. My anchor has a null PD, hidden classes share the that, so it should be fine (for now). (Class::getProtectionDomain returns an all permission PD if the class has a null PD - interesting. Looks like THAT is copied to the hidden class??) I think the original security reasoning for why proxies have a null PD is fine goes something like this: 1. The code in the proxy is trusted, aside from it will only ever calls InvocationHandler.invoke. 2. The proxy itself should not contribute to the protection domains on the stack - as it may sit between two privileged PDs. The only sensible solution to keep 2. without a null PD is to use the PD of the invocation handler - even if that PD is null. I'm not sure I like the idea of having a class with null PD in a package full of untrusted code, but that is already the case with a non-public interface. An other option is to use the PD of the caller - which gets *really* interesting with serialization (Who is the caller now?). > > That's all the feedbacks I can share so far.? We need to have a clear > idea w.r.t. serialization spec and compatibility risk to existing code > w.r.t. protection domain and explore other options. Compatibility risk is always hard to assess. But I don't think that there is any change necessary for the serialization spec. Otherwise - as only one new tests did fail - I would consider the risk low. And the failing test was in jshell, which expected a stack frame element from the proxy class. So, somewhat expected to break that. > > W.r.t. AOT tests, AOT has been disabled in openjdk build [1] and that > may be the reason why these tests fail. Thanks for the info. For now, I just ignore the failures. > > Mandy > [1] https://github.com/openjdk/jdk/pull/960 > > On 12/17/20 2:07 PM, Johannes Kuhn wrote: >> Now that class data support for hidden classes in master, I decided to >> tackle JDK-8229959 again. >> >> JDK-8229959: Convert proxy class to use constant dynamic [1] >> JDK-8242888: Convert dynamic proxy to hidden classes [2] >> >> The idea is simple: Define proxies as hidden classes, pass the methods >> as class data, and access it from the Proxy with the >> MethodHandles.classDataAt() BSM. >> >> The current prototype[3] works - and aside from one test for jshell >> that expects a stack trace element containing "jdk.proxy" as a stack >> trace element (hidden classes, duh), no new tests did fail with "make >> test-tier1". >> Also, the aot tests fail ("link.exe not found"), if someone has some >> instructions how to get them properly run on windows, I'm very >> interested. But they are not new failures. >> >> Problems I did run into: >> >> I need a lookup for a class in a package to define a hidden class. >> --------------------------- >> Solution: I inject an anchor class, obtain a lookup on it, and use >> that. The anchor is reused for the same package, and named pkg + >> ".$ProxyAnchor". >> >> I need to return both the class data & created bytecode back to Proxy >> from ProxyGenerator >> --------------------------- >> Solution: Added a record-like class that contains both bytecode as >> well as the class data. >> >> Serialization of proxies did break. >> --------------------------- >> Serializing the proxy descriptor was not a problem - the problem is >> how the constructor for serialization works. >> It spins a MagicConstructorAccessor subclass - which requires for the >> created class to have a binary name. Hidden classes don't have one. >> Solution: MethodHandles don't have this limitation, so I hacked a >> shared secret into JavaLangInvokeAccess to create such a MethodHandle, >> and replaced the Reflection.generateConstructor() implementation to >> use a ConstructorAccessor that delegates to that MethodHandle. >> >> --------------------------- >> >> In all, this is a prototype - for now, I want some feedback on the >> approach. Also a broader view - making it work is one thing. >> Checking all the right boxes in all the different areas an other. >> Some parts might still be a bit sloppy, but I want to know if there is >> merit if I follow the current path and polish it up. >> >> - Johannes >> >> PS.: I decided to use a draft PR - as with my last approaches I had >> problems when I did commit more stuff. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8229959 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8242888 >> [3]: https://github.com/openjdk/jdk/pull/1830/files >> > From jai.forums2013 at gmail.com Fri Dec 18 04:50:32 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 18 Dec 2020 10:20:32 +0530 Subject: Difference in encoding semantics of URI returned by File.toURI and Path.toUri representing the same file Message-ID: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com> The java.io.File has a toURI() API which returns a (system dependent) URI as per its javadoc. The java.io.File also has a toPath() API which then exposes a toUri() API from the java.nio.file.Path. The javadoc of the File class doesn't specify any semantics about the toUri() returned by the java.nio.file.Path. More specifically, for the same file instance, is the File.toURI() and Path.toUri() expected to return a URI which has the same semantics when it comes to encoded characters in the URI? Consider the following trivial code for what I mean: import java.net.*; import java.nio.file.*; import java.io.*; public class PathTest { ??? public static void main(final String[] args) throws Exception { ??? ??? final String location = args[0]; ??? ??? final Path a = Paths.get(location).toAbsolutePath(); ??? ??? System.out.println("URI from Paths.get().toUri() API " + a + " ---> " + a.toUri()); ??? ??? final Path b = new File(location).toPath().toAbsolutePath(); ??? ??? System.out.println("URI from File.toPath().toUri() API " + b + " ---> " + b.toUri()); ??? ??? final File c = new File(location).getAbsoluteFile(); ??? ??? System.out.println("URI from File.toURI() API " + c + " ---> " + c.toURI()); ??? } } The above program prints the URI of a file path using 3 different APIs: 1. Paths.get().toUri() 2. File.toPath().toUri() 3. File.toURI() When I run the program and pass it a directory which contains a non-ascii character (which belongs to the "other" category as explained in the URI javadoc[1]) then I see that the URI returned by the Path.toUri() differs from the URI returned from the File.toURI() when it comes to encoding the "other" category character (i.e. the non-ascii character). Here's the command I use and here's the output: mkdir foob?r java PathTest foob?r Output: URI from Paths.get().toUri() API /private/tmp/delme/foob?r ---> file:///private/tmp/delme/fooba%CC%83r/ URI from File.toPath().toUri() API /private/tmp/delme/foob?r ---> file:///private/tmp/delme/fooba%CC%83r/ URI from File.toURI() API /private/tmp/delme/foob?r ---> file:/private/tmp/delme/foob?r/ Notice that the Path.toUri() version encodes the non-ascii characters whereas the File.toURI() doesn't. Is this expected? The javadoc doesn't have much details around this. Now, interestingly, the same program if passed a file path which contains a "illegal" character (for example space character as defined in[1]), then both the Path.toUri() and File.toURI() return a URI which has the character encoded. Here's the output when you run: mkdir "foo bar" java PathTest "foo bar" Output: URI from Paths.get().toUri() API /private/tmp/delme/foo bar ---> file:///private/tmp/delme/foo%20bar URI from File.toPath().toUri() API /private/tmp/delme/foo bar ---> file:///private/tmp/delme/foo%20bar URI from File.toURI() API /private/tmp/delme/foo bar ---> file:/private/tmp/delme/foo%20bar So it's not clear which categories of the characters will be (consistently) encoded by the URI returned by the Path and File instances, for the same target file. [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/URI.html -Jaikiran From stuart.marks at oracle.com Fri Dec 18 05:31:34 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 17 Dec 2020 21:31:34 -0800 Subject: Has it been considered to add inverse methods to collections which are in Optional? In-Reply-To: <381747107.1253228.1607434221870.JavaMail.zimbra@u-pem.fr> References: <381747107.1253228.1607434221870.JavaMail.zimbra@u-pem.fr> Message-ID: <94f0c850-71da-3fc1-8c88-d6b42ecad141@oracle.com> On 12/8/20 5:30 AM, Remi Forax wrote: >> De: "Dave Franken" > Adding methods like notContains or notFilter have been considered several times in the past and rejected because it's too many methods with no real gain. I'm sure you can dig some old emails on lambda-dev and see the first iteration of the Stream API, it was full of convenient methods like that. > I'm sure Stuart or Brian have a template answer for that :) Well I don't have a template handy but I can explain some of the reasoning. :-) In general we try to avoid adding to many pure "convenience" methods that do things that are easily expressed other ways, e.g., through composition of existing methods or Java language constructs. There are many boolean-returning methods in the JDK and we've tried to avoid defining methods that are simply inverses of each other. The notable exceptions are Objects.isNull and Objects.nonNull, which seemed sensible at the time, since references being null or non-null is quite fundamental to Java programming. (Note that these are mostly useful only as method references.) Optional was introduced with isPresent, but without an inverse. Since Optional is (mostly) about having or not-having something, we later somewhat reluctantly added isEmpty, on the basis that the empty/present state of an Optional is as fundamental as null/non-null references. Another common place where inverse methods have been requested is String. We've held off doing that. String has isEmpty and isBlank, which have different semantics, so this would naturally lead to having nonEmpty and nonBlank. There are also several other boolean-returning methods on String, so you can start to see how this could lead toward excessive method proliferation. >> It would improve readability where we have the negation of isEmpty(), e.g.: >> >> if (!myList.isEmpty()) { >> } You might or might not like this syntax, but if you don't, adding new APIs here and there won't really solve anything. Personally I think adding a space after ! makes the negation stand out a bit more (and I'm used to this) so it doesn't bother me: if (! myList.isEmpty()) { ... One place where negation of a predicate does have a fairly high cost is with method references. If I have a stream where I want to filter for empty collections I could write filter(Collection::isEmpty) which is fairly nice, but if I want to filter for non-empty collections, I have to convert it to a lambda: filter(collection -> ! collection.isEmpty()) This is mitigated by the addition of a Predicate.not method, which when statically imported, allows rewriting thus: filter(not(Collection::isEmpty)) This enables using method references in a bunch of places where they couldn't be used before, relieving us of the need think of a name for the lambda parameter. In particular, this can be used with the above-mentioned String::isBlank and String::isEmpty. The main point is that Predicate.not can be used with *any* predicate, which lets us avoid adding inverse methods in a bunch of different places. s'marks From alanb at openjdk.java.net Fri Dec 18 09:12:54 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Dec 2020 09:12:54 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: On Thu, 17 Dec 2020 13:36:17 GMT, PROgrm_JARvis wrote: > Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. Are you planning to add a microbenchmark to demonstrate the issue? If there is a holder class for the MessageDigest then its initialisation can fail, this would allow the orThrow method to go away ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 13:29:23 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 13:29:23 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: On Fri, 18 Dec 2020 09:10:26 GMT, Alan Bateman wrote: > If there is a holder class for the MessageDigest then its initialisation can fail, this would allow the orThrow method to go away As of allowing `Md5Digest` instead of explicitly throwing the exception from `orThrow` I think that the latter is more appropriate as in case of allowing the class initialization to fail all non-first calls will lead to `NoClassDefFoundError` which will be counterintuitive from users' perspective although the behaviour is simply unspecified for this in contract of `nameUUIDFromBytes` (Javadoc of `MessageDigest` requires the existence of `SHA-1` and `SHA-256` but nothing is said about `MD5` (should a bug-report be raised for the purpose of specifying this detail in the Javadoc?). > Are you planning to add a microbenchmark to demonstrate the issue? As for testing I am ready to write a benchmark but I am unsure what is the canonical way to write the one comparing the value before and after changeset. Or should it simply be a comparison of the very approach used here, not exactly the changed method (i.e. writing the benchmarks using the try/catch variant and holder variant and comparing these)? Could you please give any example of such if there are some. Thanks in advance! ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From vromero at openjdk.java.net Fri Dec 18 13:34:28 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 18 Dec 2020 13:34:28 GMT Subject: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2] In-Reply-To: <34Ai7roPnyyAE9rs90cGsOaC6Y_RUo1RgGEbOSQkBxM=.8cf87ffd-dac4-4ce6-80ea-4d4a4145c195@github.com> References: <34Ai7roPnyyAE9rs90cGsOaC6Y_RUo1RgGEbOSQkBxM=.8cf87ffd-dac4-4ce6-80ea-4d4a4145c195@github.com> Message-ID: On Thu, 17 Dec 2020 10:07:13 GMT, Joel Borggr?n-Franck wrote: >> The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. >> >> This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. >> >> See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 > > Joel Borggr?n-Franck has updated the pull request incrementally with one additional commit since the last revision: > > Use constant for expected cases Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/33 From jfranck at openjdk.java.net Fri Dec 18 13:37:30 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Fri, 18 Dec 2020 13:37:30 GMT Subject: [jdk16] Integrated: 8256693: getAnnotatedReceiverType parameterizes types too eagerly In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggr?n-Franck wrote: > The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. > > See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 This pull request has now been integrated. Changeset: 1cc98bde Author: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk16/commit/1cc98bde Stats: 134 lines in 4 files changed: 107 ins; 22 del; 5 mod 8256693: getAnnotatedReceiverType parameterizes types too eagerly Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk16/pull/33 From alanb at openjdk.java.net Fri Dec 18 13:42:22 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Dec 2020 13:42:22 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: On Fri, 18 Dec 2020 13:27:02 GMT, PROgrm_JARvis wrote: >> Are you planning to add a microbenchmark to demonstrate the issue? >> If there is a holder class for the MessageDigest then its initialisation can fail, this would allow the orThrow method to go away > >> If there is a holder class for the MessageDigest then its initialisation can fail, this would allow the orThrow method to go away > > As of allowing `Md5Digest` instead of explicitly throwing the exception from `orThrow` I think that the latter is more appropriate as in case of allowing the class initialization to fail all non-first calls will lead to `NoClassDefFoundError` which will be counterintuitive from users' perspective although the behaviour is simply unspecified for this in contract of `nameUUIDFromBytes` (Javadoc of `MessageDigest` requires the existence of `SHA-1` and `SHA-256` but nothing is said about `MD5` (should a bug-report be raised for the purpose of specifying this detail in the Javadoc?). > >> Are you planning to add a microbenchmark to demonstrate the issue? > > As for testing I am ready to write a benchmark but I am unsure what is the canonical way to write the one comparing the value before and after changeset. Or should it simply be a comparison of the very approach used here, not exactly the changed method (i.e. writing the benchmarks using the try/catch variant and holder variant and comparing these)? Could you please give any example of such if there are some. > > Thanks in advance! Can you look in test/micro for existing examples? It might be that the right place to cache is in MessageDigest rather than UUID so that other code can benefit too. One other point is that Standard Algorithms specifies that MD5 is supported by MessageDigest so the JDK would be broken it could not be found. If the eventual patch is in UUID then this aspect will need a bit of cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From redestad at openjdk.java.net Fri Dec 18 14:04:24 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 18 Dec 2020 14:04:24 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: On Fri, 18 Dec 2020 13:39:48 GMT, Alan Bateman wrote: >>> If there is a holder class for the MessageDigest then its initialisation can fail, this would allow the orThrow method to go away >> >> As of allowing `Md5Digest` instead of explicitly throwing the exception from `orThrow` I think that the latter is more appropriate as in case of allowing the class initialization to fail all non-first calls will lead to `NoClassDefFoundError` which will be counterintuitive from users' perspective although the behaviour is simply unspecified for this in contract of `nameUUIDFromBytes` (Javadoc of `MessageDigest` requires the existence of `SHA-1` and `SHA-256` but nothing is said about `MD5` (should a bug-report be raised for the purpose of specifying this detail in the Javadoc?). >> >>> Are you planning to add a microbenchmark to demonstrate the issue? >> >> As for testing I am ready to write a benchmark but I am unsure what is the canonical way to write the one comparing the value before and after changeset. Or should it simply be a comparison of the very approach used here, not exactly the changed method (i.e. writing the benchmarks using the try/catch variant and holder variant and comparing these)? Could you please give any example of such if there are some. >> >> Thanks in advance! > > Can you look in test/micro for existing examples? > > It might be that the right place to cache is in MessageDigest rather than UUID so that other code can benefit too. > > One other point is that Standard Algorithms specifies that MD5 is supported by MessageDigest so the JDK would be broken it could not be found. If the eventual patch is in UUID then this aspect will need a bit of cleanup. There are pre-existing microbenchmarks for java.security under test/micro/org/openjdk/bench/java/security You can build and run these using `make test TEST=micro:YourBenchmark`. Refer to [doc/testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md) for some required configuration steps. I'd suggest starting with a simple micro that zooms in on MessageDigest.getInstance("MD5"), maybe like so: /* * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ package org.openjdk.bench.java.security; import java.security.DigestException; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.security.NoSuchProviderException; import java.util.Random; import java.util.concurrent.TimeUnit; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.Fork; import org.openjdk.jmh.annotations.Measurement; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Param; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.annotations.Warmup; /** * Tests speed of looking up MessageDigests. */ @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 5, time = 1) @Measurement(iterations = 10, time = 1) @Fork(value = 3) public class GetMessageDigest { @Benchmark @Warmup(iterations = 5, time = 1) @Measurement(iterations = 10, time = 1) public MessageDigest getMD5Digest() throws NoSuchAlgorithmException { return MessageDigest.getInstance("MD5"); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From sergei.tsypanov at yandex.ru Fri Dec 18 14:17:39 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 18 Dec 2020 16:17:39 +0200 Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: <4501741608300905@mail.yandex.ru> Hi Simon, I've removed 'but this method is likely to run significantly faster under most implementations.' so the doc is cleaner now Cheers, Sergey 17.12.2020, 16:38, "Simon Roberts" : > When updating this, might you take the opportunity to remove the ambiguous > antecedent too? The use of "this method" when there are two methods in the > discussion (Collections.addAll, and the proximate one; Collection.addAll) > is unclear (indeed, one could argue the original text might have intended > to use "this method" to refer to Collection.addAll, in which interpretation > it's correct :) > > A more specific comment on the lines of "Collection.addAll is likely to run > faster..." would entirely avoid the ambiguity. > > Perhaps that's the intended solution anyway, in which case, I apologize for > the distraction. > > On Thu, Dec 17, 2020 at 3:38 AM R?mi Forax 828220+forax at openjdk.java.net> wrote: > >> ?On Thu, 17 Dec 2020 10:15:23 GMT, ?????? ??????? > ?10835776+stsypanov at openjdk.org> wrote: >> >> ?>> Hello, I feel like this was previously discussed in >> ?https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot >> ?find original mail I post this here. >> ?>> >> ?>> Currently `Collections.addAll()` is implemented and documented as: >> ?>> /** >> ?>> * ... >> ?>> * The behavior of this convenience method is identical to that of >> ?>> * {@code c.addAll(Arrays.asList(elements))}, but this method is >> ?likely >> ?>> * to run significantly faster under most implementations. >> ?>> */ >> ?>> @SafeVarargs >> ?>> public static boolean addAll(Collection c, T... >> ?elements) { >> ?>> boolean result = false; >> ?>> for (T element : elements) >> ?>> result |= c.add(element); >> ?>> return result; >> ?>> } >> ?>> >> ?>> But it practice the notation `this method is likely to run >> ?significantly faster under most implementations` is completely wrong. When >> ?I take this [benchmark]( >> ?https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) >> ?and run it on JDK 14 I get the following results: >> ?>> (collection) >> ?(size) Score Error Units >> ?>> addAll ArrayList >> ?10 37.9 ? 1.9 ns/op >> ?>> addAll ArrayList >> ??100 83.8 ? 3.4 ns/op >> ?>> addAll ArrayList >> ?1000 678.2 ? 23.0 ns/op >> ?>> collectionsAddAll ArrayList >> ?10 50.9 ? 1.1 ns/op >> ?>> collectionsAddAll ArrayList >> ??100 751.4 ? 47.4 ns/op >> ?>> collectionsAddAll ArrayList >> ?1000 8839.8 ? 710.7 ns/op >> ?>> >> ?>> addAll HashSet >> ?10 128.4 ? 5.9 ns/op >> ?>> addAll HashSet >> ??100 1864.2 ? 102.4 ns/op >> ?>> addAll HashSet >> ?1000 16615.5 ? 1202.6 ns/op >> ?>> collectionsAddAll HashSet >> ?10 172.8 ? 6.0 ns/op >> ?>> collectionsAddAll HashSet >> ??100 2355.8 ? 195.4 ns/op >> ?>> collectionsAddAll HashSet >> ?1000 20364.7 ? 1164.0 ns/op >> ?>> >> ?>> addAll ArrayDeque >> ?10 54.0 ? 0.4 ns/op >> ?>> addAll ArrayDeque >> ??100 319.7 ? 2.5 ns/op >> ?>> addAll ArrayDeque >> ?1000 3176.9 ? 22.2 ns/op >> ?>> collectionsAddAll ArrayDeque >> ?10 66.5 ? 1.4 ns/op >> ?>> collectionsAddAll ArrayDeque >> ??100 808.1 ? 55.9 ns/op >> ?>> collectionsAddAll ArrayDeque >> ?1000 5639.6 ? 240.9 ns/op >> ?>> >> ?>> addAll CopyOnWriteArrayList >> ?10 18.0 ? 0.7 ns/op >> ?>> addAll CopyOnWriteArrayList >> ??100 39.4 ? 1.7 ns/op >> ?>> addAll CopyOnWriteArrayList >> ?1000 371.1 ? 17.0 ns/op >> ?>> collectionsAddAll CopyOnWriteArrayList >> ?10 251.9 ? 18.4 ns/op >> ?>> collectionsAddAll CopyOnWriteArrayList >> ??100 3405.9 ? 304.8 ns/op >> ?>> collectionsAddAll CopyOnWriteArrayList >> ?1000 247496.8 ? 23502.3 ns/op >> ?>> >> ?>> addAll ConcurrentLinkedDeque >> ?10 81.4 ? 2.8 ns/op >> ?>> addAll ConcurrentLinkedDeque >> ??100 609.1 ? 26.4 ns/op >> ?>> addAll ConcurrentLinkedDeque >> ?1000 4494.5 ? 219.3 ns/op >> ?>> collectionsAddAll ConcurrentLinkedDeque >> ?10 189.8 ? 2.5 ns/op >> ?>> collectionsAddAll ConcurrentLinkedDeque >> ??100 1660.0 ? 62.0 ns/op >> ?>> collectionsAddAll ConcurrentLinkedDeque >> ?1000 17649.2 ? 300.9 ns/op >> ?>> >> ?>> addAll:?gc.alloc.rate.norm ArrayList >> ?10 160.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm ArrayList >> ??100 880.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm ArrayList >> ?1000 8080.3 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ArrayList >> ?10 80.0 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ArrayList >> ??100 1400.2 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ArrayList >> ?1000 15025.6 ? 0.1 B/op >> ?>> >> ?>> addAll:?gc.alloc.rate.norm HashSet >> ?10 464.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm HashSet >> ??100 5328.5 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm HashSet >> ?1000 48516.7 ? 0.1 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm HashSet >> ?10 464.0 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm HashSet >> ??100 5328.5 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm HashSet >> ?1000 48516.6 ? 0.1 B/op >> ?>> >> ?>> addAll:?gc.alloc.rate.norm ArrayDeque >> ?10 112.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm ArrayDeque >> ??100 560.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm ArrayDeque >> ?1000 4160.5 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque >> ?10 112.0 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque >> ??100 1048.1 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ArrayDeque >> ?1000 14929.4 ? 0.0 B/op >> ?>> >> ?>> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList >> ?10 88.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList >> ??100 448.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm CopyOnWriteArrayList >> ?1000 4048.1 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList >> ?10 456.0 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList >> ??100 22057.2 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList >> ?1000 2020150.3 ? 7.3 B/op >> ?>> >> ?>> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque >> ?10 312.0 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque >> ??100 2472.1 ? 0.0 B/op >> ?>> addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque >> ?1000 24073.7 ? 0.1 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque >> ?10 288.0 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque >> ??100 2448.3 ? 0.0 B/op >> ?>> collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque >> ?1000 24051.4 ? 0.3 B/op >> ?>> There's never a case when `Collections.addAll` is fater - on the >> ?contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially >> ?to dramatic difference for array-based collection. >> ?>> >> ?>> So I propose to reimplement the method by simply delegating to >> ?`Arrays.asList` because the spec declares identical behaviour and to remove >> ?perfomance notation from JavaDoc. >> ?> >> ?> Looks like I've found the original ticket: >> ?https://bugs.openjdk.java.net/browse/JDK-8193031 >> >> ?Apart from the @SuppressWarnings, this looks good to me. >> ?And i like the irony of this. >> >> ?------------- >> >> ?PR: https://git.openjdk.java.net/jdk/pull/1764 > > -- > Simon Roberts > (303) 249 3613 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 14:25:24 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 14:25:24 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: On Fri, 18 Dec 2020 13:39:48 GMT, Alan Bateman wrote: > Can you look in test/micro for existing examples? Yes, of course, the question is more about the following: should I simply cover `UUID#nameUUIDFromBytes(byte[])` by the benchmark or should I rather write a comparison benchmark which would compare finding the MessageDigest on every iteration against using the holder for this purpose (without any direct reference to `UUID` class). > It might be that the right place to cache is in `MessageDigest` rather than `UUID` so that other code can benefit too. `UUID.Md5Digest` may be moved to `MessageDigest` but this seems to be a case to implement something similar to this in the way similar to `StandardCharsets`. > One other point is that Standard Algorithms specifies that MD5 is supported by MessageDigest so the JDK would be broken it could not be found. If the eventual patch is in UUID then this aspect will need a bit of cleanup. I've looked through [Standard Algorithms section for MessageDigest](https://docs.oracle.com/en/java/javase/15/docs/specs/security/standard-names.html#messagedigest-algorithms) and is says > Algorithm names that *can* be specified And the javadoc of `MessageDigest` says: > Every implementation of the Java platform is required to support the following standard `MessageDigest` algorithms: > - `SHA-1` > - `SHA-256` So I cannot find any requirement for `MD5` to be present. Although I believe that every implementation does provide it, it may be essential to either specify it or describe the behavior for its absence in case of `UUID`'s usage. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 14:31:22 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 14:31:22 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> On Fri, 18 Dec 2020 14:01:19 GMT, Claes Redestad wrote: > I'd suggest starting with a simple micro that zooms in on MessageDigest.getInstance("MD5"), maybe like so: Thanks, that's what I wanted to hear. I will implement it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+10835776+stsypanov at openjdk.java.net Fri Dec 18 14:37:25 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 18 Dec 2020 14:37:25 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: <7MIi_753sP-fcoaq1W9UQa8o1Kv2X43U_2gQXT-X7LU=.7bc3d162-bc64-4715-98c0-75c86bbc06bb@github.com> On Thu, 17 Dec 2020 11:07:55 GMT, R?mi Forax wrote: >> Should I then wait for the fix of that bug to remove `@SupressWarnings`? > > I don't think so, the code is fine, for me. I've looked into `com.sun.tools.javac.comp.Check` and it seems the warning is produced here: @Override public void warn(LintCategory lint) { boolean warned = this.warned; super.warn(lint); if (warned) return; // suppress redundant diagnostics switch (lint) { case UNCHECKED: Check.this.warnUnchecked(pos(), Warnings.ProbFoundReq(diags.fragment(uncheckedKey), found, expected)); break; case VARARGS: if (method != null && method.attribute(syms.trustMeType.tsym) != null && isTrustMeAllowedOnMethod(method) && !types.isReifiable(method.type.getParameterTypes().last())) { Check.this.warnUnsafeVararg(pos(), Warnings.VarargsUnsafeUseVarargsParam(method.params.last())); } break; default: throw new AssertionError("Unexpected lint: " + lint); } } Can we somehow read `@SaveVarargs` from signature of `Arrays.asList()` to avoid the warning? ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From mullan at openjdk.java.net Fri Dec 18 14:40:24 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 18 Dec 2020 14:40:24 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 14:29:00 GMT, PROgrm_JARvis wrote: >> There are pre-existing microbenchmarks for java.security under test/micro/org/openjdk/bench/java/security >> >> You can build and run these using `make test TEST=micro:YourBenchmark`. Refer to [doc/testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md) for some required configuration steps. >> >> I'd suggest starting with a simple micro that zooms in on MessageDigest.getInstance("MD5"), maybe like so: >> >> /* >> * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ >> package org.openjdk.bench.java.security; >> >> import java.security.DigestException; >> import java.security.MessageDigest; >> import java.security.NoSuchAlgorithmException; >> import java.security.NoSuchProviderException; >> import java.util.Random; >> import java.util.concurrent.TimeUnit; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.BenchmarkMode; >> import org.openjdk.jmh.annotations.Fork; >> import org.openjdk.jmh.annotations.Measurement; >> import org.openjdk.jmh.annotations.Mode; >> import org.openjdk.jmh.annotations.OutputTimeUnit; >> import org.openjdk.jmh.annotations.Param; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.Warmup; >> >> /** >> * Tests speed of looking up MessageDigests. >> */ >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Warmup(iterations = 5, time = 1) >> @Measurement(iterations = 10, time = 1) >> @Fork(value = 3) >> public class GetMessageDigest { >> >> @Benchmark >> public MessageDigest getMD5Digest() throws NoSuchAlgorithmException { >> return MessageDigest.getInstance("MD5"); >> } >> } > >> I'd suggest starting with a simple micro that zooms in on MessageDigest.getInstance("MD5"), maybe like so: > > Thanks, that's what I wanted to hear. > I will implement it now. > I've looked through [Standard Algorithms section for MessageDigest](https://docs.oracle.com/en/java/javase/15/docs/specs/security/standard-names.html#messagedigest-algorithms) and is says > > > Algorithm names that _can_ be specified > > And the javadoc of `MessageDigest` says: > > > Every implementation of the Java platform is required to support the following standard `MessageDigest` algorithms: > > > > * `SHA-1` > > * `SHA-256` > > So I cannot find any requirement for `MD5` to be present. Although I believe that every implementation does provide it, it may be essential to either specify it or describe the behavior for its absence in case of `UUID`'s usage. MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 14:45:24 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 14:45:24 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 14:37:53 GMT, Sean Mullan wrote: > MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present? ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From herrick at openjdk.java.net Fri Dec 18 14:53:25 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 18 Dec 2020 14:53:25 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> Message-ID: <6_IWOSE0E-JlJOyvbefWfgkvP4jaszXGcIqL-BnajbU=.4962ff4d-5c1b-423b-afc4-50b95f5f5610@github.com> On Thu, 17 Dec 2020 23:26:44 GMT, Alexey Semenyuk wrote: >> Changes requested by asemenyuk (Committer). > > I'd propose to update the test to run more that two concurrent instance of jpackage command. > > > Changes looks fine, but are we sure that external 3rd party tools used by jpackage will work concurrently without any issues? I don't think we can be sure of thread-safe behavior of the third party tools, the best thing we can do is thoroughly test (as requested below, run a lot more instances simultaneously). Main thing we are implementing and testing is that jpackage code itself is thread safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From redestad at openjdk.java.net Fri Dec 18 14:57:23 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 18 Dec 2020 14:57:23 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 14:42:38 GMT, PROgrm_JARvis wrote: >>> I've looked through [Standard Algorithms section for MessageDigest](https://docs.oracle.com/en/java/javase/15/docs/specs/security/standard-names.html#messagedigest-algorithms) and is says >>> >>> > Algorithm names that _can_ be specified >>> >>> And the javadoc of `MessageDigest` says: >>> >>> > Every implementation of the Java platform is required to support the following standard `MessageDigest` algorithms: >>> > >>> > * `SHA-1` >>> > * `SHA-256` >>> >>> So I cannot find any requirement for `MD5` to be present. Although I believe that every implementation does provide it, it may be essential to either specify it or describe the behavior for its absence in case of `UUID`'s usage. >> >> MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. > >> MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. > > In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present? A more general issue is that this patch assumes the `MessageDigest` object returned is statically shareable, which implies it being stateless and thread-safe. This doesn't seem to be the case. See [MD5.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/MD5.java) and the [DigestBase.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java) base class, which both have mutating buffers for doing the digest. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 15:01:30 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 15:01:30 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 14:55:08 GMT, Claes Redestad wrote: > A more general issue is that this patch assumes the `MessageDigest` object returned is statically shareable, which implies it being stateless and thread-safe. > > This doesn't seem to be the case. See [MD5.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/MD5.java) and the [DigestBase.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java) base class, which both have mutating buffers for doing the digest. Wow, this is interesting. In this case I will check if there is a way to implement a thread-safe mechanism there. Will report here once there is some result. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From herrick at openjdk.java.net Fri Dec 18 15:03:23 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 18 Dec 2020 15:03:23 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> Message-ID: On Thu, 17 Dec 2020 23:26:44 GMT, Alexey Semenyuk wrote: > > > I'd propose to update the test to run more that two concurrent instance of jpackage command. yes - I'm planning for a lot more in next revision, your suggestion to use only PackageTest.Action.CREATE will go a long way to making that possible, but I have had problems with test infrastructure fixing the workDir based on test class and method, and then getting IOExceptions as various PackageTest's try to write the same content to the same work dir. I need to create infrastructure to allow each PackageTest to operate on separate workDir. ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From herrick at openjdk.java.net Fri Dec 18 15:03:24 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 18 Dec 2020 15:03:24 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> Message-ID: On Fri, 18 Dec 2020 14:59:06 GMT, Andy Herrick wrote: >> I'd propose to update the test to run more that two concurrent instance of jpackage command. > >> >> >> I'd propose to update the test to run more that two concurrent instance of jpackage command. > > yes - I'm planning for a lot more in next revision, your suggestion to use only PackageTest.Action.CREATE will go a long way to making that possible, but I have had problems with test infrastructure fixing the workDir based on test class and method, and then getting IOExceptions as various PackageTest's try to write the same content to the same work dir. I need to create infrastructure to allow each PackageTest to operate on separate workDir. Reverting this PR to DRAFT while the above suggestions are implemented. ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From redestad at openjdk.java.net Fri Dec 18 15:29:25 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 18 Dec 2020 15:29:25 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 14:59:10 GMT, PROgrm_JARvis wrote: >> A more general issue is that this patch assumes the `MessageDigest` object returned is statically shareable, which implies it being stateless and thread-safe. >> >> This doesn't seem to be the case. See [MD5.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/MD5.java) and the [DigestBase.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java) base class, which both have mutating buffers for doing the digest. > >> A more general issue is that this patch assumes the `MessageDigest` object returned is statically shareable, which implies it being stateless and thread-safe. >> >> This doesn't seem to be the case. See [MD5.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/MD5.java) and the [DigestBase.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java) base class, which both have mutating buffers for doing the digest. > > Wow, this is interesting. In this case I will check if there is a way to implement a thread-safe mechanism there. Will report here once there is some result. Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner). ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From herrick at openjdk.java.net Fri Dec 18 15:43:39 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 18 Dec 2020 15:43:39 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> Message-ID: <-E-cgdXoL6VKOm2ncULMILPxcnaW0gZpQGEcx9ZB8H4=.ecf9af60-3d15-40a8-959c-e5e6b5e9308c@github.com> On Fri, 18 Dec 2020 15:00:13 GMT, Andy Herrick wrote: >>> >>> >>> I'd propose to update the test to run more that two concurrent instance of jpackage command. >> >> yes - I'm planning for a lot more in next revision, your suggestion to use only PackageTest.Action.CREATE will go a long way to making that possible, but I have had problems with test infrastructure fixing the workDir based on test class and method, and then getting IOExceptions as various PackageTest's try to write the same content to the same work dir. I need to create infrastructure to allow each PackageTest to operate on separate workDir. > > Reverting this PR to DRAFT while the above suggestions are implemented. > > > .removeArgumentWithValue("--type") can be used to make jpackage create default native package. This will eliminate need to introduce packageType.getDefault() method. The above will cause an exception from JPackageCommand.execute() > ... > JPackageCommand.verifyIsOfType(), but perhaps that problem will go away if only JPackageTest.run(PackageTest.Action.CREATE) is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 15:51:54 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 15:51:54 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 15:24:21 GMT, Claes Redestad wrote: > Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner). I've thought about using `ThreadLocal` at holder level and my naive benchmark shows significant improvement in speed compared to current implementation: https://gist.github.com/JarvisCraft/61cd45f83aea7f33cba9510e523a5c4e As of the state from single thread's perspective, it seems to be safe to reuse `MessageDigest` in this case: > The `digest` method can be called once for a given number of updates. After `digest` has been called, the MessageDigest object is reset to its initialized state. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 16:04:18 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 16:04:18 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached [v3] In-Reply-To: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> Message-ID: > Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. PROgrm_JARvis has updated the pull request incrementally with two additional commits since the last revision: - 8258588: add Md5MessageDigestLookup benchmark - 8258588: make UUID#Md5Digest thread-safe using ThreadLocal ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1821/files - new: https://git.openjdk.java.net/jdk/pull/1821/files/37db4c56..1abb7cfe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=01-02 Stats: 87 lines in 2 files changed: 77 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821 PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Fri Dec 18 16:04:18 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Fri, 18 Dec 2020 16:04:18 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: On Fri, 18 Dec 2020 15:48:52 GMT, PROgrm_JARvis wrote: >> Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner). > >> Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner). > > I've thought about using `ThreadLocal` at holder level and my naive benchmark shows significant improvement in speed compared to current implementation: https://gist.github.com/JarvisCraft/61cd45f83aea7f33cba9510e523a5c4e > > As of the state from single thread's perspective, it seems to be safe to reuse `MessageDigest` in this case: > >> The `digest` method can be called once for a given number of updates. After `digest` has been called, the MessageDigest object is reset to its initialized state. I've pushed the change utilizing `ThreadLocal` and my benchmark to correspond to the discussion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From mullan at openjdk.java.net Fri Dec 18 19:06:59 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 18 Dec 2020 19:06:59 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> Message-ID: <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> On Fri, 18 Dec 2020 14:42:38 GMT, PROgrm_JARvis wrote: > > MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. > > In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present? Perhaps it should throw `UnsupportedOperationException`, but I'll defer to someone who works in this area. It may also be useful to support type 5 UUIDs which use SHA-1. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From smarks at openjdk.java.net Fri Dec 18 20:13:59 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Dec 2020 20:13:59 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> Message-ID: <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> On Fri, 18 Dec 2020 19:04:36 GMT, Sean Mullan wrote: >>> MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. >> >> In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present? > >> > MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time. >> >> In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present? > > Perhaps it should throw `UnsupportedOperationException`, but I'll defer to someone who works in this area. It may also be useful to support type 5 UUIDs which use SHA-1. I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? I'd like to see a demonstration that fetching and allocating an MD5 MessageDigest instance on each call is indeed a performance problem (either because it's too slow, or because it takes too much memory). Based on that we might or might not want to do some optimization of some form or another. Or we might want to optimize creation in MessageDigest instead of caching instances in UUID. More fundamentally, I'd like to see an answer to the question, "What problem is this change intended to solve?" ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From asemenyuk at openjdk.java.net Fri Dec 18 20:26:57 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 18 Dec 2020 20:26:57 GMT Subject: RFR: JDK-8223322: Improve concurrency in jpackage instances In-Reply-To: References: <7y5zJT0API_zfkwaCOEOShD6VxQNWzXNU6TjCfT-52s=.f51329ac-9e45-4cff-9dc9-d03a74439ee8@github.com> Message-ID: On Fri, 18 Dec 2020 14:59:06 GMT, Andy Herrick wrote: > I have had problems with test infrastructure fixing the workDir based on test class and method, and then getting IOExceptions as various PackageTest's try to write the same content to the same work dir I don't think we need changes to test infrastructure to run PackageTest instances concurrently. This is how to create input for jpackage: final Path inputDir = TKit.workDir().resolve("input"); HelloApp.createBundle(JavaAppDesc.parse("hellp.jar:Hello"), inputDir); This is the function to initialize PackegTest instance that will use hello.jar initialized above to build a package and write output in unique directory inside of test work directory: private PackageTest initTest(Path inputDir, bool useToolProvider) { // Just in case if TKit.createTempDirectory is not reliable enough to be executed concurrently final Path outputDir; synchronized (this) { outputDir = TKit.createTempDirectory("output"); } return new PackageTest() .addInitializer(cmd -> { cmd.useToolProvider(useToolProvider); cmd.setArgumentValue("--input", inoutDir); cmd.setArgumentValue("--main-class", "Hello"); cmd.setArgumentValue("--dest", outputDir); }); } Glue it all together: @Test @Parameter("true") @Parameter("false") public void testIt(bool useToolProvider) { final Path inputDir = TKit.workDir().resolve("input"); HelloApp.createBundle(JavaAppDesc.parse("hellp.jar:Hello"), inputDir); final int TEST_COUNT = 5; List tasks = new ArrayList<>(); for (int i = 0; i != TEST_COUNT; i++) { tests.push(ThrowingRunnable.toRunnable(() -> initTest(inputDir, useToolProvider).run(PackageTest.Action.CREATE))); } ExecutorService exec = Executors.newCachedThreadPool(); tasks.stream().forEach(exec::execute); exec.shutdown(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1829 From bchristi at openjdk.java.net Fri Dec 18 22:39:04 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 18 Dec 2020 22:39:04 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest Message-ID: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. The new 'o' reference is kept alive until FoceGC.await() has been called. We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) ------------- Commit messages: - Don't keep ForceGC'ing until we see the expected count - Add comment about new Object reference in ForceGC - fix spacing - Keep ForceGC'ing until we see the expected count - Add strongly-referenced Object to prevent cleaning before await() is called Changes: https://git.openjdk.java.net/jdk16/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258007 Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk16/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk16/pull/53 From mchung at openjdk.java.net Fri Dec 18 22:45:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 18 Dec 2020 22:45:58 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest In-Reply-To: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: <1fpRT3TNyn1BlhCr8UEDjizGVRcfWXzdstZ1ovwFXjk=.231741c6-4281-47a5-9cc4-f0f64296411b@github.com> On Fri, 18 Dec 2020 22:33:11 GMT, Brent Christian wrote: > This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. > > It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. > > The new 'o' reference is kept alive until FoceGC.await() has been called. > > We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) This looks okay. test/lib/jdk/test/lib/util/ForceGC.java line 49: > 47: System.gc(); > 48: System.out.format("doit %d: gc %d%n", iter, i); > 49: if (cleanerInvoked.await(1L, TimeUnit.SECONDS)) { If the object that the test waits for garbage collected takes more GC cycles than the object registered in ForceGC's cleaner, this will return immediately. If you are concerned, maybe if the count down latch already becomes zero, it should call System.sleep before the next System.gc(). ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/53 From bchristi at openjdk.java.net Fri Dec 18 23:37:11 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 18 Dec 2020 23:37:11 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest [v2] In-Reply-To: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: > This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. > > It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. > > The new 'o' reference is kept alive until FoceGC.await() has been called. > > We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Add sleep to ForceGC.await() ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/53/files - new: https://git.openjdk.java.net/jdk16/pull/53/files/9b5e57ca..54a9e6d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=53&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=53&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk16/pull/53 From naoto at openjdk.java.net Fri Dec 18 23:37:11 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Dec 2020 23:37:11 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest [v2] In-Reply-To: References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: On Fri, 18 Dec 2020 23:34:04 GMT, Brent Christian wrote: >> This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. >> >> It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. >> >> The new 'o' reference is kept alive until FoceGC.await() has been called. >> >> We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Add sleep to ForceGC.await() Looks good to me. test/lib/jdk/test/lib/util/ForceGC.java line 48: > 46: for (int i = 0; i < 10; i++) { > 47: System.gc(); > 48: System.out.format("doit %d: gc %d%n", iter, i); Could be better to keep using println(), if performance is important. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/53 From bchristi at openjdk.java.net Fri Dec 18 23:37:12 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 18 Dec 2020 23:37:12 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest [v2] In-Reply-To: <1fpRT3TNyn1BlhCr8UEDjizGVRcfWXzdstZ1ovwFXjk=.231741c6-4281-47a5-9cc4-f0f64296411b@github.com> References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> <1fpRT3TNyn1BlhCr8UEDjizGVRcfWXzdstZ1ovwFXjk=.231741c6-4281-47a5-9cc4-f0f64296411b@github.com> Message-ID: On Fri, 18 Dec 2020 22:43:16 GMT, Mandy Chung wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> Add sleep to ForceGC.await() > > test/lib/jdk/test/lib/util/ForceGC.java line 49: > >> 47: System.gc(); >> 48: System.out.format("doit %d: gc %d%n", iter, i); >> 49: if (cleanerInvoked.await(1L, TimeUnit.SECONDS)) { > > If the object that the test waits for garbage collected takes more GC cycles than the object registered in ForceGC's cleaner, this will return immediately. If you are concerned, maybe if the count down latch already becomes zero, it should call System.sleep before the next System.gc(). I am a little concerned. But I think it makes more sense to sleep in await(), between calls of doit(). I'll push an update. ------------- PR: https://git.openjdk.java.net/jdk16/pull/53 From bchristi at openjdk.java.net Fri Dec 18 23:45:08 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 18 Dec 2020 23:45:08 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest [v3] In-Reply-To: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: > This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. > > It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. > > The new 'o' reference is kept alive until FoceGC.await() has been called. > > We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) Brent Christian has updated the pull request incrementally with one additional commit since the last revision: format() -> println() ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/53/files - new: https://git.openjdk.java.net/jdk16/pull/53/files/54a9e6d1..f0dd43ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=53&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=53&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk16/pull/53 From mchung at openjdk.java.net Fri Dec 18 23:45:09 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 18 Dec 2020 23:45:09 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest [v2] In-Reply-To: References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: On Fri, 18 Dec 2020 23:37:11 GMT, Brent Christian wrote: >> This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. >> >> It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. >> >> The new 'o' reference is kept alive until FoceGC.await() has been called. >> >> We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Add sleep to ForceGC.await() Marked as reviewed by mchung (Reviewer). test/lib/jdk/test/lib/util/ForceGC.java line 73: > 71: if (s.getAsBoolean()) return true; > 72: doit(i); > 73: try { Thread.sleep(1000); } catch (InterruptedException e) { nit: can you break the catch clause in a separate line. Otherwise looks good. ------------- PR: https://git.openjdk.java.net/jdk16/pull/53 From bchristi at openjdk.java.net Fri Dec 18 23:45:10 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 18 Dec 2020 23:45:10 GMT Subject: [jdk16] RFR: 8258007: Add instrumentation to NativeLibraryTest [v3] In-Reply-To: References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: <7_BIGUisTYxmpYKFwGvESJ7KvpqPwCm9ivSMXzWQiUc=.ba8bc549-fad7-4454-8fdd-ae68d117b717@github.com> On Fri, 18 Dec 2020 23:31:35 GMT, Naoto Sato wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> format() -> println() > > test/lib/jdk/test/lib/util/ForceGC.java line 48: > >> 46: for (int i = 0; i < 10; i++) { >> 47: System.gc(); >> 48: System.out.format("doit %d: gc %d%n", iter, i); > > Could be better to keep using println(), if performance is important. I agree we don't need format() here ------------- PR: https://git.openjdk.java.net/jdk16/pull/53 From bchristi at openjdk.java.net Sat Dec 19 00:19:58 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Sat, 19 Dec 2020 00:19:58 GMT Subject: [jdk16] Integrated: 8258007: Add instrumentation to NativeLibraryTest In-Reply-To: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> References: <2cv1RG7GP1Lc7VlQ-a77zPGrZDT7aasVW06VPLxNOIw=.af413148-a5c1-4ee7-b7e6-d640a37840e2@github.com> Message-ID: On Fri, 18 Dec 2020 22:33:11 GMT, Brent Christian wrote: > This change adds some extra test output for NativeLibraryTest, primarily via an update to the ForceGC utility class. > > It was observed that there was nothing preventing the Cleaner from cleaning the short-lived Object that ForceGC registers before await()/doit()/System.gc() is even called. > > The new 'o' reference is kept alive until FoceGC.await() has been called. > > We should find out a little more the next time NativeLibraryTest fails (or perhaps it won't fail anymore!) This pull request has now been integrated. Changeset: e680ebeb Author: Brent Christian URL: https://git.openjdk.java.net/jdk16/commit/e680ebeb Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod 8258007: Add instrumentation to NativeLibraryTest Reviewed-by: mchung, naoto ------------- PR: https://git.openjdk.java.net/jdk16/pull/53 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Dec 19 09:12:57 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 19 Dec 2020 09:12:57 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 10:36:17 GMT, R?mi Forax wrote: >> Looks like I've found the original ticket: https://bugs.openjdk.java.net/browse/JDK-8193031 > > Apart from the @SuppressWarnings, this looks good to me. > And i like the irony of this. Hi all, According to the document of [SafeVarargs](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/SafeVarargs.html). > Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where: > The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable arity parameter's array that generates an unchecked warning. The `SafeVarargs` may not suppress the warning of this assignment and the `SuppressWarnings` may be necessary. If you still think it is the bug of compiler. I suggest that you move the bug discussion to the compiler-dev at openjdk.java.net to solve the bug as soon as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From jiefu at openjdk.java.net Sat Dec 19 09:45:09 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 19 Dec 2020 09:45:09 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v2] In-Reply-To: References: Message-ID: > Hi all, > > java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implementation only supports maximum 3800M on 32-bit systems [1]. > > I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. > So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. > The fix just skips the test for 32-bit systems. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 Jie Fu has updated the pull request incrementally with two additional commits since the last revision: - Ignore OOME for testOOME - Revert the change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1817/files - new: https://git.openjdk.java.net/jdk/pull/1817/files/6b32101d..38d4d01a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1817&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1817&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1817/head:pull/1817 PR: https://git.openjdk.java.net/jdk/pull/1817 From jiefu at openjdk.java.net Sat Dec 19 09:47:55 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 19 Dec 2020 09:47:55 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 16:14:56 GMT, Roger Riggs wrote: > Disabling all of the tests on 32 bit is not a good idea. > > Instead the HexFormatTest.testOOME test should be skipped or the OOME should be ignored. > Checking Runtime.getRuntime().maxMemory() should provide enough info to skip it. Thanks @RogerRiggs for your review and comments. Let's ignore the OOME for testOOME. What do you think of the updated change? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1817 From chegar at openjdk.java.net Sat Dec 19 10:31:55 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Sat, 19 Dec 2020 10:31:55 GMT Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4] In-Reply-To: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 13:16:31 GMT, Aleksei Efimov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base >> take advantage of "flow scoping" to eliminate casts > > Thank you for checking `HttpURLConnection` and `Socket`. > The latest version looks good to me. This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this. [1]: https://bugs.openjdk.java.net/browse/JDK-8258657 ------------- PR: https://git.openjdk.java.net/jdk/pull/20 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 17:10:02 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 17:10:02 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Message-ID: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo ------------- Commit messages: - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo Changes: https://git.openjdk.java.net/jdk/pull/1853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8080272 Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 17:46:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 17:46:10 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v2] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes in JrtPath. They compiled with java 8 language level ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From openjdk at icemanx.nl Sun Dec 20 17:47:17 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Sun, 20 Dec 2020 18:47:17 +0100 Subject: [BUG] InputStream.readNBytes doesn't correctly check for EOF Message-ID: According to the documentation of InputStream.readNBytes: Reads up to a specified number of bytes from the input stream. This method blocks until the requested number of bytes have been read, end of stream is detected, or an exception is thrown. This method does not close the input stream. However, despite a comment, currently it may not necessarily read up to EOF. The problem is in a small result checking error: // read to EOF which may read more or less than buffer size while ((n = read(buf, nread, Math.min(buf.length - nread, remaining))) > 0) { nread += n; remaining -= n; } That "> 0" is incorrect here; it's allowed to return 0 before EOF has been reached. It should be ">= 0", "> -1" or "!= -1", all of which correctly treat 0 and only break the loop once the read operation returns -1. Based on what's used in transferTo the best choice is probably ">= 0", to remain consistent in the same file. From kustos at gmx.net Sun Dec 20 18:15:32 2020 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 20 Dec 2020 19:15:32 +0100 Subject: [BUG] InputStream.readNBytes doesn't correctly check for EOF In-Reply-To: References: Message-ID: <6b4de0ff-7be2-5eb1-7318-429a5a30b0c3@gmx.net> On 20.12.20 18:47, Rob Spoor wrote: > ... > > That "> 0" is incorrect here; it's allowed to return 0 before EOF I don't think the method is allowed to return 0 before EOF. To quote from the method Javadoc. > This method blocks until input data is available, end of file is detected, or an exception is thrown. > If no byte is available because the stream is at end of file, the value {@code -1} is returned; otherwise, at least one byte is read and stored into {@code b}. Cheers Philippe From alanb at openjdk.java.net Sun Dec 20 19:45:54 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 20 Dec 2020 19:45:54 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage. We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch. One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Sun Dec 20 19:51:55 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 20 Dec 2020 19:51:55 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> Message-ID: <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQWBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> On Fri, 18 Dec 2020 20:11:26 GMT, Stuart Marks wrote: > I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:09:12 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:09:12 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v3] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes in ASM use Files.copy in sjavac ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01-02 Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:15:09 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:15:09 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v4] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo use Files.copy in MLet too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:22:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:22:10 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v5] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo use Files.copy in Win32PrintJob too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03-04 Stats: 14 lines in 1 file changed: 2 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sun Dec 20 20:25:52 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Dec 2020 20:25:52 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman wrote: > One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From prr at openjdk.java.net Sun Dec 20 20:36:56 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 20 Dec 2020 20:36:56 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov wrote: >> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage. >> >> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch. >> >> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. > >> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. > > Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive. So these changes are all over the place which means no one person knows how to test all of it. Have you run the sound, swing tests, and the printing tests on unix and windows ? For printing for sure you'll need to do some manual testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From redestad at openjdk.java.net Sun Dec 20 20:48:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 20 Dec 2020 20:48:58 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQWBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman wrote: >> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? >> >> I'd like to see a demonstration that fetching and allocating an MD5 MessageDigest instance on each call is indeed a performance problem (either because it's too slow, or because it takes too much memory). Based on that we might or might not want to do some optimization of some form or another. Or we might want to optimize creation in MessageDigest instead of caching instances in UUID. More fundamentally, I'd like to see an answer to the question, "What problem is this change intended to solve?" > >> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? > > This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options. As Stuart argues a TL approach is likely to look better in a microbenchmark, but make things worse in other regards. I started exploring options to this in #1855 (not logged an RFE, yet), and I think there is potential to get most of the gains seen here without the introduction of a `ThreadLocal`. The current patch also speeds up MD5.digest for small chunks (+19% for 16 bytes, but less relative impact on larger chunks, down to being lost in the noise on 16Kb). Speed-up of `UUID.nameUUIDFromBytes` is somewhat modest right now (+4%, -17% allocations), but I think it can be improved further without complicating things too much. The MD5 intrinsic added by JDK-8250902 adds some constraints on the implementation that holds back some polish. This can be fixed, but requires some coordination. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From redestad at openjdk.java.net Sun Dec 20 21:48:56 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 20 Dec 2020 21:48:56 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Sun, 20 Dec 2020 20:45:55 GMT, Claes Redestad wrote: >>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? >> >> This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options. > > As Stuart argues a TL approach is likely to look better in a microbenchmark, but make things worse in other regards. > > I started exploring options to this in #1855 (not logged an RFE, yet), and I think there is potential to get most of the gains seen here without the introduction of a `ThreadLocal`. The current patch also speeds up MD5.digest for small chunks (+19% for 16 bytes, but less relative impact on larger chunks, down to being lost in the noise on 16Kb). Speed-up of `UUID.nameUUIDFromBytes` is somewhat modest right now (+4%, -17% allocations), but I think it can be improved further without complicating things too much. The MD5 intrinsic added by JDK-8250902 adds some constraints on the implementation that holds back some polish. This can be fixed, but requires some coordination. A trick that could be used here instead of `ThreadLocal` is to store an instance of MD5 retrieved via MessageDigest.getInstance, but clone it before use. See [this commit](https://github.com/openjdk/jdk/pull/1855/commits/2f266316d62ca875c38e2f771412d02625414bf4). This maintains thread safety, avoids the allure of TLs, and gives a substantial speed-up on the `UUIDBench.fromType3Bytes` micro (comparing it against the other optimizations that were already in #1855): Benchmark (size) Mode Cnt Score Error Units UUIDBench.fromType3Bytes 20000 thrpt 12 1.523 ? 0.066 ops/us UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 408.036 ? 0.003 B/op Benchmark (size) Mode Cnt Score Error Units UUIDBench.fromType3Bytes 20000 thrpt 12 2.186 ? 0.228 ops/us UUIDBench.fromType3Bytes:?gc.alloc.rate.norm 20000 thrpt 12 264.023 ? 0.006 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From github.com+7693005+jarviscraft at openjdk.java.net Sun Dec 20 22:43:54 2020 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Sun, 20 Dec 2020 22:43:54 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQWBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman wrote: > I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol? Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative. Currently, I will keep this PR open but I expect this to be superseded by the latter. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From serb at openjdk.java.net Sun Dec 20 22:50:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 20 Dec 2020 22:50:55 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race wrote: >>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java. >> >> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive. > > So these changes are all over the place which means no one person knows how to test all of it. > Have you run the sound, swing tests, and the printing tests on unix and windows ? > For printing for sure you'll need to do some manual testing. I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 07:52:10 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 07:52:10 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v6] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/ec602c1a..6f8ec711 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04-05 Stats: 135 lines in 13 files changed: 102 ins; 2 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 07:58:59 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 07:58:59 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov wrote: >> So these changes are all over the place which means no one person knows how to test all of it. >> Have you run the sound, swing tests, and the printing tests on unix and windows ? >> For printing for sure you'll need to do some manual testing. > > I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR. I've extracted changes in java.desktop into separate PR #1856 Reverted this changes from current PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 08:19:08 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 08:19:08 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v7] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6f8ec711..fceb20e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05-06 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Mon Dec 21 08:36:56 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 21 Dec 2020 08:36:56 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo In-Reply-To: References: Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com> On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov wrote: >> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR. > > I've extracted changes in java.desktop into separate PR #1856 > Reverted this changes from current PR. Probably best to drop the changes to src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/** too as it gets refreshed periodically from the upstream Apache Santuario project. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From akozlov at openjdk.java.net Mon Dec 21 08:47:55 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 21 Dec 2020 08:47:55 GMT Subject: Integrated: 8257620: Do not use objc_msgSend_stret to get macOS version In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available. This pull request has now been integrated. Changeset: d4c7db50 Author: Anton Kozlov Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/d4c7db50 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod 8257620: Do not use objc_msgSend_stret to get macOS version Reviewed-by: ihse, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/1569 From jwilhelm at openjdk.java.net Mon Dec 21 09:14:13 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 21 Dec 2020 09:14:13 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:05:48 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: d2343880 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/d2343880 Stats: 1822 lines in 76 files changed: 1281 ins; 263 del; 278 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1857 From jwilhelm at openjdk.java.net Mon Dec 21 09:14:12 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 21 Dec 2020 09:14:12 GMT Subject: Integrated: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258007: Add instrumentation to NativeLibraryTest - 8258002: Update "type" terminology in generated docs - 8223607: --override-methods=summary ignores some signature changes - 8258687: Build broken on Windows after fix for JDK-8258134 - 8256693: getAnnotatedReceiverType parameterizes types too eagerly - 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack - 8258134: assert(size == calc_size) failed: incorrect size calculation on x86_32 with AVX512 machines - 8257974: Regression 21% in DaCapo-lusearch-large after JDK-8236926 - 8258373: Update the text handling in the JPasswordField - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d4c7db50...67de4667 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1857&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1857&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1857/files Stats: 1822 lines in 76 files changed: 1281 ins; 263 del; 278 mod Patch: https://git.openjdk.java.net/jdk/pull/1857.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1857/head:pull/1857 PR: https://git.openjdk.java.net/jdk/pull/1857 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 09:16:11 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 09:16:11 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes in Apache Santuario ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/fceb20e3..94e99817 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06-07 Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 09:47:59 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 09:47:59 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes in Apache Santuario I'm not a reviewer, but still think we could simplify `sun.security.tools.keytool.Main` src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459: > 2457: byte[] bytes = in.readAllBytes(); > 2458: return CertificateFactory.getInstance("X509").generateCRLs( > 2459: new ByteArrayInputStream(bytes)); Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 09:53:11 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 09:53:11 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v3] In-Reply-To: References: Message-ID: > Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this convenience method is identical to that of > * {@code c.addAll(Arrays.asList(elements))}, but this method is likely > * to run significantly faster under most implementations. > */ > @SafeVarargs > public static boolean addAll(Collection c, T... elements) { > boolean result = false; > for (T element : elements) > result |= c.add(element); > return result; > } > > But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: > (collection) (size) Score Error Units > addAll ArrayList 10 37.9 ? 1.9 ns/op > addAll ArrayList 100 83.8 ? 3.4 ns/op > addAll ArrayList 1000 678.2 ? 23.0 ns/op > collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op > collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op > collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op > > addAll HashSet 10 128.4 ? 5.9 ns/op > addAll HashSet 100 1864.2 ? 102.4 ns/op > addAll HashSet 1000 16615.5 ? 1202.6 ns/op > collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op > collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op > collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op > > addAll ArrayDeque 10 54.0 ? 0.4 ns/op > addAll ArrayDeque 100 319.7 ? 2.5 ns/op > addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op > collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op > collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op > collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op > > addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op > addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op > addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op > collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op > collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op > collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op > > addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op > addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op > addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op > collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op > collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op > collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op > > addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op > > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op > > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op > There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. > > So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/add-all' into add-all - 8193031: add elements in bulk in Collections.addAll() - Merge branch 'master' into add-all - 8193031: add elements in bulk in Collections.addAll() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1764/files - new: https://git.openjdk.java.net/jdk/pull/1764/files/0e33c906..7667b8a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=01-02 Stats: 5818 lines in 284 files changed: 3251 ins; 1139 del; 1428 mod Patch: https://git.openjdk.java.net/jdk/pull/1764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764 PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+741251+turbanoff at openjdk.java.net Mon Dec 21 09:53:57 2020 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Dec 2020 09:53:57 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459: > >> 2457: byte[] bytes = in.readAllBytes(); >> 2458: return CertificateFactory.getInstance("X509").generateCRLs( >> 2459: new ByteArrayInputStream(bytes)); > > Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again? Looks like it was done intentionally by original author of the code. Check comment above: // Read the full stream before feeding to X509Factory, // otherwise, keytool -gencrl | keytool -printcrl // might not work properly, since -gencrl is slow // and there's no data in the pipe at the beginning. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 10:06:01 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 10:06:01 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459: >> >>> 2457: byte[] bytes = in.readAllBytes(); >>> 2458: return CertificateFactory.getInstance("X509").generateCRLs( >>> 2459: new ByteArrayInputStream(bytes)); >> >> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again? > > Looks like it was done intentionally by original author of the code. > Check comment above: > > // Read the full stream before feeding to X509Factory, > // otherwise, keytool -gencrl | keytool -printcrl > // might not work properly, since -gencrl is slow > // and there's no data in the pipe at the beginning. Let's keep it then ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From openjdk at icemanx.nl Mon Dec 21 10:06:47 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Mon, 21 Dec 2020 11:06:47 +0100 Subject: [BUG] InputStream.readNBytes doesn't correctly check for EOF In-Reply-To: <6b4de0ff-7be2-5eb1-7318-429a5a30b0c3@gmx.net> References: <6b4de0ff-7be2-5eb1-7318-429a5a30b0c3@gmx.net> Message-ID: On 20/12/2020 19:15, Philippe Marschall wrote: > > > On 20.12.20 18:47, Rob Spoor wrote: >> ... >> >> That "> 0" is incorrect here; it's allowed to return 0 before EOF > > I don't think the method is allowed to return 0 before EOF. To quote > from the method Javadoc. > > > This method blocks until input data is available, end of file is > detected, or an exception is thrown. > > > If no byte is available because the stream is at end of file, the > value {@code -1} is returned; otherwise, at least one byte is read and > stored into {@code b}. > > Cheers > Philippe Hi Philippe, You are right about the readNBytes method itself. I was talking about the read(byte[], int, int) method that is used internally by readNBytes. That method may return 0 before EOF, and if it does then readNBytes returns before it should. From martin.doerr at sap.com Mon Dec 21 10:52:24 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 10:52:24 +0000 Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Message-ID: Hi, JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly, because https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()). Bug: https://bugs.openjdk.java.net/browse/JDK-8235351 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce 11u backport: http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/ This is the adaptation: diff -r a670e0826a66 src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 06 15:10:40 2019 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 18 18:01:25 2020 +0100 @@ -2074,8 +2074,8 @@ * Otherwise, if m is caller-sensitive, throw IllegalAccessException. */ Lookup findBoundCallerLookup(MemberName m) throws IllegalAccessException { - if (MethodHandleNatives.isCallerSensitive(m) && !hasFullPrivilegeAccess()) { - // Only lookups with full privilege access are allowed to resolve caller-sensitive methods + if (MethodHandleNatives.isCallerSensitive(m) && !hasPrivateAccess()) { + // Only lookups with private access are allowed to resolve caller-sensitive methods throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); } return this; @@ -2335,9 +2335,9 @@ if (boundCaller.allowedModes == TRUSTED || !MethodHandleNatives.isCallerSensitive(method)) return mh; - // boundCaller must have full privilege access. + // boundCaller must have private access. // It should have been checked by findBoundCallerLookup. Safe to check this again. - if (!boundCaller.hasFullPrivilegeAccess()) + if (!boundCaller.hasPrivateAccess()) throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, boundCaller.lookupClass); Please review. Best regards, Martin From prappo at openjdk.java.net Mon Dec 21 11:34:57 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 21 Dec 2020 11:34:57 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: On Sat, 19 Dec 2020 09:09:50 GMT, Guoxiong Li wrote: >> Apart from the @SuppressWarnings, this looks good to me. >> And i like the irony of this. > > Hi all, > > According to the document of [SafeVarargs](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/SafeVarargs.html). > >> Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where: > >> The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable arity parameter's array that generates an unchecked warning. > > The `SafeVarargs` may not suppress the warning of this assignment and the `SuppressWarnings` may be necessary. > > If you still think it is the bug of compiler. I suggest that you move the bug discussion to the compiler-dev at openjdk.java.net to solve the bug as soon as possible. This message is purely informational: I may have found a JBS comment that provides historical context for that "this method is likely to run significantly faster under most implementations" phrase. Here: https://bugs.openjdk.java.net/browse/JDK-4822887?focusedCommentId=12241154&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12241154 ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From dl at openjdk.java.net Mon Dec 21 12:39:56 2020 From: dl at openjdk.java.net (Doug Lea) Date: Mon, 21 Dec 2020 12:39:56 GMT Subject: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 05:54:24 GMT, Martin Buchholz wrote: >> 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates > > Martin Buchholz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by dl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1645 From dl at openjdk.java.net Mon Dec 21 12:39:59 2020 From: dl at openjdk.java.net (Doug Lea) Date: Mon, 21 Dec 2020 12:39:59 GMT Subject: RFR: 8246585: ForkJoin updates [v3] In-Reply-To: References: Message-ID: <1-kOHZctEPs5raIR0I19airq-KdWnzrbpBqvS807GCg=.79b9a561-d7b6-4be6-a07d-269cc2e636e0@github.com> On Wed, 9 Dec 2020 20:20:49 GMT, Martin Buchholz wrote: >> 8246585: ForkJoin updates > > Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > JDK-8246585 Marked as reviewed by dl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1646 From dl at openjdk.java.net Mon Dec 21 12:45:00 2020 From: dl at openjdk.java.net (Doug Lea) Date: Mon, 21 Dec 2020 12:45:00 GMT Subject: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v4] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 00:40:08 GMT, Martin Buchholz wrote: >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > JDK-8234131 Marked as reviewed by dl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1647 From goetz.lindenmaier at sap.com Mon Dec 21 13:44:19 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Dec 2020 13:44:19 +0000 Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag In-Reply-To: References: Message-ID: Hi Martin, The change looks good. The private methods have been called at those places before, so this is straight forward. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 21, 2020 11:52 AM To: core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Hi, JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly, because https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()). Bug: https://bugs.openjdk.java.net/browse/JDK-8235351 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce 11u backport: http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/ This is the adaptation: diff -r a670e0826a66 src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 06 15:10:40 2019 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 18 18:01:25 2020 +0100 @@ -2074,8 +2074,8 @@ * Otherwise, if m is caller-sensitive, throw IllegalAccessException. */ Lookup findBoundCallerLookup(MemberName m) throws IllegalAccessException { - if (MethodHandleNatives.isCallerSensitive(m) && !hasFullPrivilegeAccess()) { - // Only lookups with full privilege access are allowed to resolve caller-sensitive methods + if (MethodHandleNatives.isCallerSensitive(m) && !hasPrivateAccess()) { + // Only lookups with private access are allowed to resolve caller-sensitive methods throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); } return this; @@ -2335,9 +2335,9 @@ if (boundCaller.allowedModes == TRUSTED || !MethodHandleNatives.isCallerSensitive(method)) return mh; - // boundCaller must have full privilege access. + // boundCaller must have private access. // It should have been checked by findBoundCallerLookup. Safe to check this again. - if (!boundCaller.hasFullPrivilegeAccess()) + if (!boundCaller.hasPrivateAccess()) throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, boundCaller.lookupClass); Please review. Best regards, Martin From martin.doerr at sap.com Mon Dec 21 13:51:04 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 13:51:04 +0000 Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Montag, 21. Dezember 2020 14:44 To: Doerr, Martin ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Hi Martin, The change looks good. The private methods have been called at those places before, so this is straight forward. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 21, 2020 11:52 AM To: core-libs-dev >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Hi, JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly, because https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()). Bug: https://bugs.openjdk.java.net/browse/JDK-8235351 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce 11u backport: http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/ This is the adaptation: diff -r a670e0826a66 src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 06 15:10:40 2019 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 18 18:01:25 2020 +0100 @@ -2074,8 +2074,8 @@ * Otherwise, if m is caller-sensitive, throw IllegalAccessException. */ Lookup findBoundCallerLookup(MemberName m) throws IllegalAccessException { - if (MethodHandleNatives.isCallerSensitive(m) && !hasFullPrivilegeAccess()) { - // Only lookups with full privilege access are allowed to resolve caller-sensitive methods + if (MethodHandleNatives.isCallerSensitive(m) && !hasPrivateAccess()) { + // Only lookups with private access are allowed to resolve caller-sensitive methods throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); } return this; @@ -2335,9 +2335,9 @@ if (boundCaller.allowedModes == TRUSTED || !MethodHandleNatives.isCallerSensitive(method)) return mh; - // boundCaller must have full privilege access. + // boundCaller must have private access. // It should have been checked by findBoundCallerLookup. Safe to check this again. - if (!boundCaller.hasFullPrivilegeAccess()) + if (!boundCaller.hasPrivateAccess()) throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, boundCaller.lookupClass); Please review. Best regards, Martin From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 14:30:02 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 14:30:02 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 11:32:28 GMT, Pavel Rappo wrote: >> Hi all, >> >> According to the document of [SafeVarargs](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/SafeVarargs.html). >> >>> Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where: >> >>> The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable arity parameter's array that generates an unchecked warning. >> >> The `SafeVarargs` may not suppress the warning of this assignment and the `SuppressWarnings` may be necessary. >> >> If you still think it is the bug of compiler. I suggest that you move the bug discussion to the compiler-dev at openjdk.java.net to solve the bug as soon as possible. > > This message is purely informational: I may have found a JBS comment that provides historical context for that "this method is likely to run significantly faster under most implementations" phrase. Here: https://bugs.openjdk.java.net/browse/JDK-4822887?focusedCommentId=12241154&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12241154 @pavelrappo the problem is that people still believe this message and use this utility method widely: see e.g. https://github.com/spring-projects/spring-framework/pull/23478 They expect it to improve performance, but in fact it degradates. Also for some cases it degrade dramatically, e.g. when instead of `ArrayList` `COWArrayList` comes as argument @pavelrappo also see this not very old comment: https://github.com/spring-projects/spring-framework/pull/24636#pullrequestreview-370684078 ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 21 14:40:56 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 21 Dec 2020 14:40:56 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 11:07:55 GMT, R?mi Forax wrote: >> Should I then wait for the fix of that bug to remove `@SupressWarnings`? > > I don't think so, the code is fine, for me. @forax I've sent a mail into compiler-dev list: http://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015857.html Let's see what they decide. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From prappo at openjdk.java.net Mon Dec 21 15:25:56 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 21 Dec 2020 15:25:56 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 14:26:45 GMT, ?????? ??????? wrote: >> This message is purely informational: I may have found a JBS comment that provides historical context for that "this method is likely to run significantly faster under most implementations" phrase. Here: https://bugs.openjdk.java.net/browse/JDK-4822887?focusedCommentId=12241154&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12241154 > > @pavelrappo also see this not very old comment: https://github.com/spring-projects/spring-framework/pull/24636#pullrequestreview-370684078 "This message" referred to the entirety of that very comment of mine https://github.com/openjdk/jdk/pull/1764#issuecomment-748926986 I prepended that message with that clause (that is, the wording to the left of the colon) to make it clear that I didn't want to review or argue with anything said before that in that thread; it seems that clause made more harm than good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From rriggs at openjdk.java.net Mon Dec 21 15:36:55 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 21 Dec 2020 15:36:55 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v2] In-Reply-To: References: Message-ID: On Sat, 19 Dec 2020 09:45:09 GMT, Jie Fu wrote: >> Hi all, >> >> java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. >> The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. >> The current implementation only supports maximum 3800M on 32-bit systems [1]. >> >> I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. >> So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. >> The fix just skips the test for 32-bit systems. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 > > Jie Fu has updated the pull request incrementally with two additional commits since the last revision: > > - Ignore OOME for testOOME > - Revert the change Completely ignoring the exception will leave no trace that the test was skipped or why. Please retain the printing of the memory limits and instead of rethrowing the oome add: new SkipException("Insufficient Memory to test OOME");``` (It will need an import of org.testng.SkipException). Throwing SkipException will flag the test as being skipped in the Jtreg summary. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1817 From martin.doerr at sap.com Mon Dec 21 20:53:52 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 20:53:52 +0000 Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Message-ID: Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but 11u needs minor adaptation: - Keep "import java.util.Iterator;" in Module.java. - "toModuleInfo" has one argument less in 11u, so pass one "null" less. Bug: https://bugs.openjdk.java.net/browse/JDK-8241770 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30 11u backport: http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/ Manual change in detail: diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 2020 +0100 @@ -42,6 +42,7 @@ import java.security.PrivilegedAction; import java.util.HashMap; import java.util.HashSet; +import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Objects; diff -r d85e41e89ed5 src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Mon Dec 21 21:23:47 2020 +0100 @@ -184,7 +184,7 @@ * module-info.class format. */ public static byte[] toBytes(ModuleDescriptor descriptor) { - return toModuleInfo(descriptor, null, null); + return toModuleInfo(descriptor, null); } /** Please review. Best regards, Martin From jiefu at openjdk.java.net Mon Dec 21 23:37:08 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 21 Dec 2020 23:37:08 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v3] In-Reply-To: References: Message-ID: > Hi all, > > java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implementation only supports maximum 3800M on 32-bit systems [1]. > > I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. > So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. > The fix just skips the test for 32-bit systems. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Skip OOME ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1817/files - new: https://git.openjdk.java.net/jdk/pull/1817/files/38d4d01a..83cbdaaf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1817&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1817&range=01-02 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1817/head:pull/1817 PR: https://git.openjdk.java.net/jdk/pull/1817 From rriggs at openjdk.java.net Mon Dec 21 23:41:53 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 21 Dec 2020 23:41:53 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v3] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 23:37:08 GMT, Jie Fu wrote: >> Hi all, >> >> java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. >> The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. >> The current implementation only supports maximum 3800M on 32-bit systems [1]. >> >> I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. >> So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. >> The fix just skips the test for 32-bit systems. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Skip OOME Looks fine. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1817 From jiefu at openjdk.java.net Mon Dec 21 23:41:55 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 21 Dec 2020 23:41:55 GMT Subject: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v2] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 15:34:16 GMT, Roger Riggs wrote: >> Jie Fu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Ignore OOME for testOOME >> - Revert the change > > Completely ignoring the exception will leave no trace that the test was skipped or why. > Please retain the printing of the memory limits and instead of rethrowing the oome add: > new SkipException("Insufficient Memory to test OOME");``` > (It will need an import of org.testng.SkipException). > Throwing SkipException will flag the test as being skipped in the Jtreg summary. > Completely ignoring the exception will leave no trace that the test was skipped or why. > Please retain the printing of the memory limits and instead of rethrowing the oome add: > `throw new SkipException("Insufficient Memory to test OOME");` > (It will need an import of org.testng.SkipException). > Throwing SkipException will flag the test as being skipped in the Jtreg summary. Updated. Thanks for your help. ------------- PR: https://git.openjdk.java.net/jdk/pull/1817 From jjg at openjdk.java.net Mon Dec 21 23:55:54 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 21 Dec 2020 23:55:54 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v2] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 14:37:57 GMT, ?????? ??????? wrote: >> I don't think so, the code is fine, for me. > > @forax I've sent a mail into compiler-dev list: http://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015857.html > > Let's see what they decide. FYI, despite the confusing (historical) name, `syms.trustMeType` is the `SafeVarargs` annotation. See `Symtab.java`, line 579. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From jiefu at openjdk.java.net Tue Dec 22 02:09:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 22 Dec 2020 02:09:56 GMT Subject: Integrated: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 12:11:33 GMT, Jie Fu wrote: > Hi all, > > java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implementation only supports maximum 3800M on 32-bit systems [1]. > > I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. > So this test seems to be brittle on 32-bit platforms since 2G is already larger than 3800M/2=1900M. > The fix just skips the test for 32-bit systems. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 This pull request has now been integrated. Changeset: 1594372c Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/1594372c Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/1817 From goetz.lindenmaier at sap.com Tue Dec 22 12:01:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Dec 2020 12:01:32 +0000 Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module In-Reply-To: References: Message-ID: Hi Martin, The change looks good. The additional argument is only used for an optional printout of platform information, so not relevant for this fix - besides that it is null anyways. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 21, 2020 9:54 PM To: core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but 11u needs minor adaptation: - Keep "import java.util.Iterator;" in Module.java. - "toModuleInfo" has one argument less in 11u, so pass one "null" less. Bug: https://bugs.openjdk.java.net/browse/JDK-8241770 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30 11u backport: http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/ Manual change in detail: diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 2020 +0100 @@ -42,6 +42,7 @@ import java.security.PrivilegedAction; import java.util.HashMap; import java.util.HashSet; +import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Objects; diff -r d85e41e89ed5 src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Mon Dec 21 21:23:47 2020 +0100 @@ -184,7 +184,7 @@ * module-info.class format. */ public static byte[] toBytes(ModuleDescriptor descriptor) { - return toModuleInfo(descriptor, null, null); + return toModuleInfo(descriptor, null); } /** Please review. Best regards, Martin From martin.doerr at sap.com Tue Dec 22 13:12:06 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Dec 2020 13:12:06 +0000 Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 22. Dezember 2020 13:02 To: Doerr, Martin ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Hi Martin, The change looks good. The additional argument is only used for an optional printout of platform information, so not relevant for this fix - besides that it is null anyways. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 21, 2020 9:54 PM To: core-libs-dev >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but 11u needs minor adaptation: - Keep "import java.util.Iterator;" in Module.java. - "toModuleInfo" has one argument less in 11u, so pass one "null" less. Bug: https://bugs.openjdk.java.net/browse/JDK-8241770 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30 11u backport: http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/ Manual change in detail: diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 2020 +0100 @@ -42,6 +42,7 @@ import java.security.PrivilegedAction; import java.util.HashMap; import java.util.HashSet; +import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Objects; diff -r d85e41e89ed5 src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Mon Dec 21 21:23:47 2020 +0100 @@ -184,7 +184,7 @@ * module-info.class format. */ public static byte[] toBytes(ModuleDescriptor descriptor) { - return toModuleInfo(descriptor, null, null); + return toModuleInfo(descriptor, null); } /** Please review. Best regards, Martin From weijun at openjdk.java.net Tue Dec 22 15:51:05 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 22 Dec 2020 15:51:05 GMT Subject: RFR: 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject() Message-ID: The method is useless now since the related TLS cipher suite was removed long ago. ------------- Commit messages: - 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject() Changes: https://git.openjdk.java.net/jdk/pull/1865/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1865&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258631 Stats: 25 lines in 1 file changed: 0 ins; 24 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1865/head:pull/1865 PR: https://git.openjdk.java.net/jdk/pull/1865 From dcubed at openjdk.java.net Tue Dec 22 17:03:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:03:05 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Message-ID: ProblemList two java/rmi/Naming tests on Windows in order to reduce the noise in the JDK16 CI. This is a trivial fix. ------------- Commit messages: - 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Changes: https://git.openjdk.java.net/jdk16/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258827 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/58/head:pull/58 PR: https://git.openjdk.java.net/jdk16/pull/58 From msheppar at openjdk.java.net Tue Dec 22 17:18:59 2020 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 22 Dec 2020 17:18:59 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. LGTM ------------- Marked as reviewed by msheppar (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/58 From rriggs at openjdk.java.net Tue Dec 22 17:18:59 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Dec 2020 17:18:59 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:19:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:19:00 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 17:14:24 GMT, Phil Race wrote: >> ProblemList two java/rmi/Naming tests on Windows in order to reduce the >> noise in the JDK16 CI. This is a trivial fix. > > overdue Thanks for the fast reviews! ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From prr at openjdk.java.net Tue Dec 22 17:19:00 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 22 Dec 2020 17:19:00 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. overdue ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:19:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:19:01 GMT Subject: [jdk16] Integrated: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: <49rEuRYk_yWrf0W7mmQ16jRX3BlcOw0Xj-2-jGaqDqQ=.3b9cb617-a8b6-4b56-8ce0-01f9d4dc3aa0@github.com> On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. This pull request has now been integrated. Changeset: eabc9030 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/eabc9030 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Reviewed-by: rriggs, msheppar, prr ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From kustos at gmx.net Tue Dec 22 17:36:43 2020 From: kustos at gmx.net (Philippe Marschall) Date: Tue, 22 Dec 2020 18:36:43 +0100 Subject: [BUG] InputStream.readNBytes doesn't correctly check for EOF In-Reply-To: <6b4de0ff-7be2-5eb1-7318-429a5a30b0c3@gmx.net> References: <6b4de0ff-7be2-5eb1-7318-429a5a30b0c3@gmx.net> Message-ID: On 20.12.20 19:15, Philippe Marschall wrote: > > > On 20.12.20 18:47, Rob Spoor wrote: >> ... >> >> That "> 0" is incorrect here; it's allowed to return 0 before EOF > > I don't think the method is allowed to return 0 before EOF. To quote > from the method Javadoc. > > > This method blocks until input data is available, end of file is > detected, or an exception is thrown. > > > If no byte is available because the stream is at end of file, the > value {@code -1} is returned; otherwise, at least one byte is read and > stored into {@code b}. Hello Rob For whatever reason I see your reply only in the web interface and not in my mail client so I reply to my mail instead. The Javadoc I posted is from InputStream.read(byte[], int, int). Therefore I don't think that InputStream.read(byte[], int, int) is allowed to return 0 unless len is 0 in which case the loop is supposed to terminate. Cheers Philippe From hoffmann at mountainminds.com Tue Dec 22 19:58:05 2020 From: hoffmann at mountainminds.com (Marc Hoffmann) Date: Tue, 22 Dec 2020 20:58:05 +0100 Subject: Accidentally public inner classes in JDK APIs? Message-ID: <9A76CE9E-DF9A-49B0-A168-CCA438CE160F@mountainminds.com> Dear core libs developers, I recently noted that the JDK lib implementation comes with a list of public inner classes nested in package private classes. Either these classes are explicitly flagged as public or they become implicitly public when they are nested in interfaces (in accordance to JLS). Full list for JDK 11 see below. These classes cannot be referenced in source files as the parent types cannot be resolved. But access e.g. via reflection is possible: Class clazz = Class.forName("java.lang.WeakPairMap$Pair$Lookup"); System.out.println(Modifier.isPublic(clazz.getModifiers())); Question: Are there any guidelines regarding visibility of such inner classes? I think in many cases the visibility could be reduced. Is that something that is worth a bug or patch? Regards, -marc Public inner classes nested in non-public classes in JDK11: java/awt/EventFilter$FilterAction java/lang/FdLibm$Cbrt java/lang/FdLibm$Hypot java/lang/FdLibm$Pow java/lang/LiveStackFrame$PrimitiveSlot java/lang/WeakPairMap$Pair$Lookup java/lang/WeakPairMap$Pair$Weak java/lang/invoke/ClassSpecializer$Factory java/lang/invoke/ClassSpecializer$SpeciesData java/util/stream/Node$Builder java/util/stream/Node$OfDouble java/util/stream/Node$OfInt java/util/stream/Node$OfLong java/util/stream/Node$OfPrimitive java/util/stream/Sink$ChainedDouble java/util/stream/Sink$ChainedInt java/util/stream/Sink$ChainedLong java/util/stream/Sink$ChainedReference java/util/stream/Sink$OfDouble java/util/stream/Sink$OfInt java/util/stream/Sink$OfLong javax/swing/MultiUIDefaults$MultiUIDefaultsEnumerator$Type javax/swing/plaf/basic/DragRecognitionSupport$BeforeDrag javax/swing/plaf/metal/MetalSplitPaneDivider$MetalDividerLayout javax/swing/plaf/nimbus/Effect$ArrayCache javax/swing/text/html/AccessibleHTML$HTMLAccessibleContext javax/swing/text/html/AccessibleHTML$IconElementInfo$IconAccessibleContext javax/swing/text/html/AccessibleHTML$TableElementInfo$TableAccessibleContext javax/swing/text/html/AccessibleHTML$TextElementInfo$TextAccessibleContext javax/swing/text/html/TableView$RowView javax/xml/catalog/GroupEntry$PreferType javax/xml/catalog/GroupEntry$ResolveType From turbanoff at gmail.com Wed Dec 23 13:10:02 2020 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 23 Dec 2020 16:10:02 +0300 Subject: Confusing 'null'-check in JDK-8235961 fix Message-ID: Hello. I've found confusing placement of `null` check in the fix for JDK-8235961 Method 'com.sun.rowset.CachedRowSetImpl#getColIdxByName' private int getColIdxByName(String name) throws SQLException { RowSetMD = (RowSetMetaDataImpl)this.getMetaData(); int cols = RowSetMD.getColumnCount(); if (RowSetMD != null) { for (int i = 1; i <= cols; ++i) { String colName = RowSetMD.getColumnName(i); if (colName != null) if (name.equalsIgnoreCase(colName)) return (i); else continue; } } throw new SQLException(resBundle.handleGetObject("cachedrowsetimpl.invalcolnm").toString()); } As you can see, field 'RowSetMD' is checked for 'null' _after_ dereferencing. I think proper code should look like this: private int getColIdxByName(String name) throws SQLException { RowSetMD = (RowSetMetaDataImpl)this.getMetaData(); if (RowSetMD != null) { int cols = RowSetMD.getColumnCount(); for (int i = 1; i <= cols; ++i) { ... Andrey Turbanov From yano-masanori at fujitsu.com Wed Dec 23 08:01:04 2020 From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com) Date: Wed, 23 Dec 2020 08:01:04 +0000 Subject: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Message-ID: Hello, Please reply if anyone can be a sponsor. Regards, Masanori Yano > -----Original Message----- > From: Yano, Masanori > Sent: Wednesday, November 4, 2020 6:03 PM > To: 'core-libs-dev at openjdk.java.net' > Subject: 8250678: ModuleDescriptor.Version parsing treats empty segments > inconsistently > > Hello. > > I would like to contribute for JDK-8250678. > > The 'parse' method of ModuleDescriptor.Version class behaves incorrectly when the > input string contains consecutive delimiters. > > The 'parse' method treats strings as three sections, but the parsing method differs > between the method for the version sections and the ones for others. > In version sections, the 'parse' method takes a single character in a loop and > determines whether it is a delimiter. In pre and build sections, the parse method takes > two characters in a loop and determines whether the second character is the delimiter. > Therefore, if the string contains a sequence of delimiters in pre or build section, the > 'parse' method treats character at the odd-numbered position as a token and the one > at even-numbered as a delimiter > > A string containing consecutive delimiters is an incorrect version string, but this > behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/ > module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of the pre section and the build section > in the same way as the version. > > Please sponsor the following change. > > diff -r bdc20ee1a68d > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > Fri Sep 04 23:51:26 2020 -0400 > +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > Wed Oct 28 17:06:47 2020 +0900 > @@ -1053,13 +1053,6 @@ > > while (i < n) { > c = v.charAt(i); > - if (c >= '0' && c <= '9') > - i = takeNumber(v, i, pre); > - else > - i = takeString(v, i, pre); > - if (i >= n) > - break; > - c = v.charAt(i); > if (c == '.' || c == '-') { > i++; > continue; > @@ -1068,6 +1061,10 @@ > i++; > break; > } > + if (c >= '0' && c <= '9') > + i = takeNumber(v, i, pre); > + else > + i = takeString(v, i, pre); > } > > if (c == '+' && i >= n) > @@ -1075,17 +1072,14 @@ > > while (i < n) { > c = v.charAt(i); > + if (c == '.' || c == '-' || c == '+') { > + i++; > + continue; > + } > if (c >= '0' && c <= '9') > i = takeNumber(v, i, build); > else > i = takeString(v, i, build); > - if (i >= n) > - break; > - c = v.charAt(i); > - if (c == '.' || c == '-' || c == '+') { > - i++; > - continue; > - } > } > > this.version = v; > diff -r bdc20ee1a68d test/jdk/java/lang/module/VersionTest.java > --- a/test/jdk/java/lang/module/VersionTest.java Fri Sep 04 23:51:26 2020 > -0400 > +++ b/test/jdk/java/lang/module/VersionTest.java Wed Oct 28 17:06:47 > 2020 +0900 > @@ -148,6 +148,8 @@ > { "1", "1.0.0" }, > { "1.0", "1.0.0" }, > { "1.0-beta", "1.0.0-beta" }, > + { "1.0-1.1", "1.0-1..1" }, > + { "1.0-1+1", "1.0-1.+1" }, > > }; > } > > Regards, > Masanori Yano From kbarrett at openjdk.java.net Sat Dec 26 03:49:02 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 26 Dec 2020 03:49:02 GMT Subject: RFR: 8132984: incorrect type for Reference.discovered Message-ID: Please review this change which fixes the type of the private Reference.discovered field. It was Reference, but that's wrong because it can be any Reference object. I've changed it to Reference and let that flow through, updating some other variables that were previously somewhat incorrectly typed (usually with an Object type parameter). The interesting change is to the ReferenceQueue.enqueue parameter, which is now also Reference. This ultimately end up with a provably safe and correct, but uncheckable, cast in ReferenceQueue.enqueue. An alternative might be to use a raw type for the discovered field, but I think that ends up with more @SuppressWarnings of various flavors. I think the unbounded wildcard approach is clearer and cleaner. Note that all of the pending list handling, including the discovered field, could be moved into a non-public, non-generic, sealed(?) base class of Reference. The pending list handling has nothing to do with the generic parameter T. Testing: mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run) ------------- Commit messages: - Use unbounded wildcard placeholders and final safe but unchecked cast Changes: https://git.openjdk.java.net/jdk/pull/1897/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1897&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8132984 Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1897/head:pull/1897 PR: https://git.openjdk.java.net/jdk/pull/1897 From github.com+27751938+amcap1712 at openjdk.java.net Sat Dec 26 23:34:55 2020 From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri) Date: Sat, 26 Dec 2020 23:34:55 GMT Subject: Withdrawn: 8248122: java.base should not handle JavaFX application in a specific way In-Reply-To: References: Message-ID: <6mRhvDiX2SWJfPzkauuPG7BFpkj8nN7yvABguWxgGuA=.b3dbc87e-abab-428f-a2f3-79a143e9aa8d@github.com> On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri wrote: > JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code. > > Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance, > https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96 > https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353 > I think we should remove this code as well and the related tests for it. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/978 From martin at openjdk.java.net Mon Dec 28 00:41:22 2020 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 28 Dec 2020 00:41:22 GMT Subject: RFR: 8246585: ForkJoin updates [v4] In-Reply-To: References: Message-ID: > 8246585: ForkJoin updates Martin Buchholz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: JDK-8246585 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1646&range=03 Stats: 3580 lines in 9 files changed: 1603 ins; 893 del; 1084 mod Patch: https://git.openjdk.java.net/jdk/pull/1646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1646/head:pull/1646 PR: https://git.openjdk.java.net/jdk/pull/1646 From brett.okken.os at gmail.com Mon Dec 28 19:16:25 2020 From: brett.okken.os at gmail.com (Brett Okken) Date: Mon, 28 Dec 2020 13:16:25 -0600 Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory Message-ID: I am cross posting this from the nio-dev mailing list. The javadoc for SoftReference states: All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. As pointed out in the nio-dev thread, there are some exceptions to this when it is obvious that clearing soft references would not prevent the OOME. A simple example is trying to instantiate an array of size Integer.MAX_VALUE. My question, however, relates to allocating direct ByteBuffer instances. Would it be possible to clear softly-reachable direct ByteBuffer instances prior to throwing java.lang.OutOfMemoryError: Direct buffer memory? This would make it much simpler (and safer) to implement a cache of direct ByteBuffer instances for re-use. A potential use for this would be in sun.nio.ch.Util. JDK-8175230 introduced the ability to control the max size of direct ByteBuffer to cache, so as to avoid the OOME. There could be value in moving to a tiered caching strategy. The current approach of thread local values could be used for small instances. A second tier, for larger sizes (say >=64KB) could be shared among all threads and the cached instances be softly referenced. This would continue to avoid an OOME, but provide reuse for large direct ByteBuffers, which can be expensive to allocate/destroy. Thanks, Brett From github.com+10835776+stsypanov at openjdk.java.net Mon Dec 28 21:38:16 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 28 Dec 2020 21:38:16 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v4] In-Reply-To: References: Message-ID: <8bfswoT9VGBUtoUPeo0H90vLn30wiYXanf5TSbL2DdE=.4a9cbc63-f81a-44b1-86f3-67187bf80712@github.com> > Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this convenience method is identical to that of > * {@code c.addAll(Arrays.asList(elements))}, but this method is likely > * to run significantly faster under most implementations. > */ > @SafeVarargs > public static boolean addAll(Collection c, T... elements) { > boolean result = false; > for (T element : elements) > result |= c.add(element); > return result; > } > > But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: > (collection) (size) Score Error Units > addAll ArrayList 10 37.9 ? 1.9 ns/op > addAll ArrayList 100 83.8 ? 3.4 ns/op > addAll ArrayList 1000 678.2 ? 23.0 ns/op > collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op > collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op > collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op > > addAll HashSet 10 128.4 ? 5.9 ns/op > addAll HashSet 100 1864.2 ? 102.4 ns/op > addAll HashSet 1000 16615.5 ? 1202.6 ns/op > collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op > collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op > collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op > > addAll ArrayDeque 10 54.0 ? 0.4 ns/op > addAll ArrayDeque 100 319.7 ? 2.5 ns/op > addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op > collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op > collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op > collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op > > addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op > addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op > addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op > collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op > collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op > collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op > > addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op > addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op > addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op > collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op > collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op > collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op > > addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op > > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op > > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op > There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. > > So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into add-all - Merge remote-tracking branch 'origin/add-all' into add-all - 8193031: add elements in bulk in Collections.addAll() - Merge branch 'master' into add-all - 8193031: add elements in bulk in Collections.addAll() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1764/files - new: https://git.openjdk.java.net/jdk/pull/1764/files/7667b8a7..c438d282 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=02-03 Stats: 2061 lines in 133 files changed: 1780 ins; 90 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/1764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764 PR: https://git.openjdk.java.net/jdk/pull/1764 From jonathan.gibbons at oracle.com Tue Dec 29 03:45:49 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 28 Dec 2020 19:45:49 -0800 Subject: RFR: 8248122: java.base should not handle JavaFX application in a specific way In-Reply-To: References: Message-ID: <7ec56306-ecd9-98ae-af89-0b0f24ebcebf@oracle.com> On 10/31/20 8:37 AM, Kartik Ohri wrote: > Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance, > https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96 > https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353 > I think we should remove this code as well and the related tests for it. This would need to be discussed on javadoc-dev (at least), but at this time, there are no plans to remove JavaFX support from the javadoc tool. -- Jon From david.holmes at oracle.com Tue Dec 29 06:57:55 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Dec 2020 16:57:55 +1000 Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory In-Reply-To: References: Message-ID: <436adeb3-beca-090f-bcfc-243190f0b8f1@oracle.com> Hi Brett, On 29/12/2020 5:16 am, Brett Okken wrote: > I am cross posting this from the nio-dev mailing list. > > The javadoc for SoftReference states: > > All soft references to softly-reachable objects are guaranteed to have > been cleared before the virtual machine throws an OutOfMemoryError. > As pointed out in the nio-dev thread, there are some exceptions to > this when it is obvious that clearing soft references would not > prevent the OOME. A simple example is trying to instantiate an array > of size Integer.MAX_VALUE. More accurately soft-references will be cleared before throwing an OOME due to Java heap exhaustion. There are other things that can throw OOME (like your array example, or "throw new OutOfMemoryError();") that don't correspond to heap exhaustion and and so soft-reference clearing doesn't enter the picture. > My question, however, relates to allocating direct ByteBuffer > instances. Would it be possible to clear softly-reachable direct > ByteBuffer > instances prior to throwing java.lang.OutOfMemoryError: Direct buffer memory? This may be a question for the GC guys as there is no exposed API for directly requesting the GC undertake specific activities (System.gc() is just a request and exactly what it will do is not specified.) Generalizing, I presume what you are really looking for is a way to force cleaners and/or finalizers to run to try and release direct buffer memory. And I'm pretty sure that is a question that has been asked many times so I'll let other re-state the response to that. Cheers, David ----- > This would make it much simpler (and safer) to implement a cache of > direct ByteBuffer instances for re-use. A potential use for this would > be in sun.nio.ch.Util. JDK-8175230 introduced the ability to control > the max size of direct ByteBuffer to cache, so as to avoid the OOME. > There could be value in moving to a tiered caching strategy. The > current approach of thread local values could be used for small > instances. > A second tier, for larger sizes (say >=64KB) could be shared among all > threads and the cached instances be softly referenced. This would > continue to avoid an OOME, but provide reuse for large direct > ByteBuffers, which can be expensive to allocate/destroy. > > Thanks, > > Brett > From fw at deneb.enyo.de Tue Dec 29 09:15:02 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 29 Dec 2020 10:15:02 +0100 Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory In-Reply-To: <436adeb3-beca-090f-bcfc-243190f0b8f1@oracle.com> (David Holmes's message of "Tue, 29 Dec 2020 16:57:55 +1000") References: <436adeb3-beca-090f-bcfc-243190f0b8f1@oracle.com> Message-ID: <87h7o5rn1l.fsf@mid.deneb.enyo.de> * David Holmes: > More accurately soft-references will be cleared before throwing an OOME > due to Java heap exhaustion. There are other things that can throw OOME > (like your array example, or "throw new OutOfMemoryError();") that don't > correspond to heap exhaustion and and so soft-reference clearing doesn't > enter the picture. I think it's still a bug in the spec due to the way it is worded. From plevart at openjdk.java.net Tue Dec 29 10:24:02 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 29 Dec 2020 10:24:02 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: Message-ID: <1fcWoUorgA7FRyhasTd5LnrPmxJJgbuAER_TREaDyss=.6e583297-89a3-428f-b232-56b8e777680f@github.com> On Mon, 21 Dec 2020 15:23:06 GMT, Pavel Rappo wrote: >> @pavelrappo also see this not very old comment: https://github.com/spring-projects/spring-framework/pull/24636#pullrequestreview-370684078 > > "This message" referred to the entirety of that very comment of mine https://github.com/openjdk/jdk/pull/1764#issuecomment-748926986 > > I prepended that message with that clause (that is, the wording to the left of the colon) to make it clear that I didn't want to review or argue with anything said before that in that thread; it seems that clause made more harm than good. Hi, Sorry for joining late to this discussion, but I think that changing this method to delegate to c.addAll(Arrays.asList(...)) might not be the best thing to do here. Why? - This might look as a convenience method, but it takes only 2 characters less to type Collections.addAll(c, ...) than it takes to type c.addAll(Arrays.asList(...)), so we would basically end up with two ways of performing the same thing. I think we can make a method that would be worth more than that. - Pursuing performance is a noble goal, but performance is not everything. Predictability and guarantees are also important. The convenience method, being varargs method, can also be invoked with an array in place of varargs argument. Current implementation is trusted (part of JDK) and guarantees to never modify the passed-in array argument. If this was modified to just delegate to Collection.addAll(Arrays.asList(array)), it depends on the concrete implementation of the .addAll method of the implementation class of the collection. Misbehaving collection implementation could modify the passed-in Arrays.asList and such modifications would propagate to the array. So I would preferably do one of two things here. Either change the javadoc to describe current behaviour better, or use some other immutable List wrapper different than Arrays.asList() which is mutable. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From plevart at openjdk.java.net Tue Dec 29 10:44:58 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 29 Dec 2020 10:44:58 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: <1fcWoUorgA7FRyhasTd5LnrPmxJJgbuAER_TREaDyss=.6e583297-89a3-428f-b232-56b8e777680f@github.com> References: <1fcWoUorgA7FRyhasTd5LnrPmxJJgbuAER_TREaDyss=.6e583297-89a3-428f-b232-56b8e777680f@github.com> Message-ID: On Tue, 29 Dec 2020 10:21:07 GMT, Peter Levart wrote: >> "This message" referred to the entirety of that very comment of mine https://github.com/openjdk/jdk/pull/1764#issuecomment-748926986 >> >> I prepended that message with that clause (that is, the wording to the left of the colon) to make it clear that I didn't want to review or argue with anything said before that in that thread; it seems that clause made more harm than good. > > Hi, > Sorry for joining late to this discussion, but I think that changing this method to delegate to c.addAll(Arrays.asList(...)) might not be the best thing to do here. Why? > - This might look as a convenience method, but it takes only 2 characters less to type Collections.addAll(c, ...) than it takes to type c.addAll(Arrays.asList(...)), so we would basically end up with two ways of performing the same thing. I think we can make a method that would be worth more than that. > - Pursuing performance is a noble goal, but performance is not everything. Predictability and guarantees are also important. The convenience method, being varargs method, can also be invoked with an array in place of varargs argument. Current implementation is trusted (part of JDK) and guarantees to never modify the passed-in array argument. If this was modified to just delegate to Collection.addAll(Arrays.asList(array)), it depends on the concrete implementation of the .addAll method of the implementation class of the collection. Misbehaving collection implementation could modify the passed-in Arrays.asList and such modifications would propagate to the array. > > So I would preferably do one of two things here. Either change the javadoc to describe current behaviour better, or use some other immutable List wrapper different than Arrays.asList() which is mutable. WDYT? Hint: you could use `java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed` if only this method would allow other types of arrays, not just Object[]... I really don't know why this restriction couldn't be lifted as the captured array is fully encapsulated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From plevart at openjdk.java.net Tue Dec 29 10:59:01 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 29 Dec 2020 10:59:01 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: <1fcWoUorgA7FRyhasTd5LnrPmxJJgbuAER_TREaDyss=.6e583297-89a3-428f-b232-56b8e777680f@github.com> Message-ID: On Tue, 29 Dec 2020 10:42:18 GMT, Peter Levart wrote: >> Hi, >> Sorry for joining late to this discussion, but I think that changing this method to delegate to c.addAll(Arrays.asList(...)) might not be the best thing to do here. Why? >> - This might look as a convenience method, but it takes only 2 characters less to type Collections.addAll(c, ...) than it takes to type c.addAll(Arrays.asList(...)), so we would basically end up with two ways of performing the same thing. I think we can make a method that would be worth more than that. >> - Pursuing performance is a noble goal, but performance is not everything. Predictability and guarantees are also important. The convenience method, being varargs method, can also be invoked with an array in place of varargs argument. Current implementation is trusted (part of JDK) and guarantees to never modify the passed-in array argument. If this was modified to just delegate to Collection.addAll(Arrays.asList(array)), it depends on the concrete implementation of the .addAll method of the implementation class of the collection. Misbehaving collection implementation could modify the passed-in Arrays.asList and such modifications would propagate to the array. >> >> So I would preferably do one of two things here. Either change the javadoc to describe current behaviour better, or use some other immutable List wrapper different than Arrays.asList() which is mutable. WDYT? > > Hint: you could use `java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed` if only this method would allow other types of arrays, not just Object[]... I really don't know why this restriction couldn't be lifted as the captured array is fully encapsulated. On a second thought, using `java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed` is not a good idea, since the method expects the passed-in array to be trusted and use of this method in `Collections.addAll(col, array)` would wrap an untrusted array. Surely the resulting List would only be used as an argument to `col.addAll(list)`, but since neither `col` is trusted, it could "steal" the passed-in `list` and use it... Some other implementation of immutable list array wrapper would be needed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From some-java-user-99206970363698485155 at vodafonemail.de Tue Dec 29 13:42:30 2020 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Tue, 29 Dec 2020 14:42:30 +0100 (CET) Subject: Is SharedSecrets thread-safe? Message-ID: <938640011.238938.1609249350345@mail.vodafone.de> Hello, the class `jdk.internal.access.SharedSecrets` provides getter methods which all look similar to this: ``` if (static_field == null) { initialize(); } return static_field; ``` However, neither the static fields are `volatile` nor are the getter methods synchronized. So if my understanding of the Java Memory Model is correct, the compiler is free to reorder the two static field reads. So it is in theory possible that the first read yields a non-`null` value, but the second read yields a `null` value which leads to incorrect behavior (for further reading [1]). It is probably rather unlikely that this actually happens because `SharedSecrets` is in most cases accessed from static initializers (which are only run once) and because not many classes access the same `SharedSecrets` fields. Is this analysis correct or did I forget to consider parts of the Memory Model logic, or is there some JVM magic I am missing? Kind regards [1] https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient From info at j-kuhn.de Tue Dec 29 13:55:22 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 29 Dec 2020 14:55:22 +0100 Subject: Is SharedSecrets thread-safe? In-Reply-To: <938640011.238938.1609249350345@mail.vodafone.de> References: <938640011.238938.1609249350345@mail.vodafone.de> Message-ID: <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> Depends on what `initialize()` is. If it (at least) reads a volatile field, then the compiler can't reorder the second read before the first. - Johannes On 29-Dec-20 14:42, some-java-user-99206970363698485155 at vodafonemail.de wrote: > Hello, > the class `jdk.internal.access.SharedSecrets` provides getter methods which all look similar to this: > ``` > if (static_field == null) { > initialize(); > } > return static_field; > ``` > > However, neither the static fields are `volatile` nor are the getter methods synchronized. So if my > understanding of the Java Memory Model is correct, the compiler is free to reorder the two static > field reads. So it is in theory possible that the first read yields a non-`null` value, but the > second read yields a `null` value which leads to incorrect behavior (for further reading [1]). > > It is probably rather unlikely that this actually happens because `SharedSecrets` is in most cases > accessed from static initializers (which are only run once) and because not many classes access the > same `SharedSecrets` fields. > > Is this analysis correct or did I forget to consider parts of the Memory Model logic, or is there > some JVM magic I am missing? > > Kind regards > > [1] https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient > From claes.redestad at oracle.com Tue Dec 29 14:55:22 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 29 Dec 2020 15:55:22 +0100 Subject: Is SharedSecrets thread-safe? In-Reply-To: <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> Message-ID: <1c4319a0-57cf-b44a-3ad3-1a6a8971fe01@oracle.com> All the shared secrets are injected as a side effect of loading the class the getter ensures is initialized - which should provide the necessary constraints to ensure there is no way for a reordering to happen where the access object returned can be observed to be null. E.g. if (javaSecuritySignatureAccess == null) { ensureClassInitialized(Signature.class); } return javaSecuritySignatureAccess; Signature.java: static { SharedSecrets.setJavaSecuritySignatureAccess(...); } /Claes On 2020-12-29 14:55, Johannes Kuhn wrote: > Depends on what `initialize()` is. > > If it (at least) reads a volatile field, then the compiler can't reorder > the second read before the first. > > - Johannes > > On 29-Dec-20 14:42, some-java-user-99206970363698485155 at vodafonemail.de > wrote: >> Hello, >> the class `jdk.internal.access.SharedSecrets` provides getter methods >> which all look similar to this: >> ``` >> if (static_field == null) { >> ?? initialize(); >> } >> return static_field; >> ``` >> >> However, neither the static fields are `volatile` nor are the getter >> methods synchronized. So if my >> understanding of the Java Memory Model is correct, the compiler is >> free to reorder the two static >> field reads. So it is in theory possible that the first read yields a >> non-`null` value, but the >> second read yields a `null` value which leads to incorrect behavior >> (for further reading [1]). >> >> It is probably rather unlikely that this actually happens because >> `SharedSecrets` is in most cases >> accessed from static initializers (which are only run once) and >> because not many classes access the >> same `SharedSecrets` fields. >> >> Is this analysis correct or did I forget to consider parts of the >> Memory Model logic, or is there >> some JVM magic I am missing? >> >> Kind regards >> >> [1] >> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient >> >> From fw at deneb.enyo.de Tue Dec 29 15:00:45 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 29 Dec 2020 16:00:45 +0100 Subject: Is SharedSecrets thread-safe? In-Reply-To: <938640011.238938.1609249350345@mail.vodafone.de> (some-java-user's message of "Tue, 29 Dec 2020 14:42:30 +0100 (CET)") References: <938640011.238938.1609249350345@mail.vodafone.de> Message-ID: <87lfdgpsgy.fsf@mid.deneb.enyo.de> * some-java-user: > However, neither the static fields are `volatile` nor are the getter > methods synchronized. So if my understanding of the Java Memory > Model is correct, the compiler is free to reorder the two static > field reads. So it is in theory possible that the first read yields > a non-`null` value, but the second read yields a `null` value which > leads to incorrect behavior (for further reading [1]). > [1] https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient Can the JVM be multi-threaded at this point? If not, program order results in the desired behavior. From hboehm at google.com Tue Dec 29 17:53:11 2020 From: hboehm at google.com (Hans Boehm) Date: Tue, 29 Dec 2020 09:53:11 -0800 Subject: Is SharedSecrets thread-safe? In-Reply-To: <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> Message-ID: On Tue, Dec 29, 2020 at 5:56 AM Johannes Kuhn wrote: > > Depends on what `initialize()` is. > > If it (at least) reads a volatile field, then the compiler can't reorder > the second read before the first. > > - Johannes I disagree with this claim. I have no idea whether concurrency is possible here, so it may not matter. See below. > > On 29-Dec-20 14:42, some-java-user-99206970363698485155 at vodafonemail.de > wrote: > > Hello, > > the class `jdk.internal.access.SharedSecrets` provides getter methods which all look similar to this: > > ``` > > if (static_field == null) { > > initialize(); > > } > > return static_field; > > ``` If static_field is not volatile, and set concurrently, then the first read of static_field may return non-null and the second null, without initialize() even being executed. The Java memory model does not prevent reordering of non-volatile reads from the same field (for good reason). Even if initialize() is executed and performs a volatile read, this reasoning doesn't hold. The initial static_field read may be delayed past the volatile read inside the conditional and hence, at least theoretically, past the second read. Control dependencies don't order reads, either in Java, or in modern weakly-ordered architectures with branch prediction. This doesn't matter if initialize() sets static_field. This all assumes that having two threads call initialize() is OK. Java code with data races is extremely tricky and rarely correct. Hans From david.holmes at oracle.com Tue Dec 29 20:36:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Dec 2020 06:36:18 +1000 Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory In-Reply-To: <87h7o5rn1l.fsf@mid.deneb.enyo.de> References: <436adeb3-beca-090f-bcfc-243190f0b8f1@oracle.com> <87h7o5rn1l.fsf@mid.deneb.enyo.de> Message-ID: <7b79b892-f68c-d645-e3c9-c4a9f0dcd547@oracle.com> On 29/12/2020 7:15 pm, Florian Weimer wrote: > * David Holmes: > >> More accurately soft-references will be cleared before throwing an OOME >> due to Java heap exhaustion. There are other things that can throw OOME >> (like your array example, or "throw new OutOfMemoryError();") that don't >> correspond to heap exhaustion and and so soft-reference clearing doesn't >> enter the picture. > > I think it's still a bug in the spec due to the way it is worded. Yes: "All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError." s/virtual machine/garbage collector/ Cheers, David From github.com+10835776+stsypanov at openjdk.java.net Tue Dec 29 20:43:13 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 29 Dec 2020 20:43:13 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v5] In-Reply-To: References: Message-ID: > Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this convenience method is identical to that of > * {@code c.addAll(Arrays.asList(elements))}, but this method is likely > * to run significantly faster under most implementations. > */ > @SafeVarargs > public static boolean addAll(Collection c, T... elements) { > boolean result = false; > for (T element : elements) > result |= c.add(element); > return result; > } > > But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-runners/src/main/java/com/luxoft/logeek/benchmark/collection/CollectionsAddAllVsAddAllBenchmark.java) and run it on JDK 14 I get the following results: > (collection) (size) Score Error Units > addAll ArrayList 10 37.9 ? 1.9 ns/op > addAll ArrayList 100 83.8 ? 3.4 ns/op > addAll ArrayList 1000 678.2 ? 23.0 ns/op > collectionsAddAll ArrayList 10 50.9 ? 1.1 ns/op > collectionsAddAll ArrayList 100 751.4 ? 47.4 ns/op > collectionsAddAll ArrayList 1000 8839.8 ? 710.7 ns/op > > addAll HashSet 10 128.4 ? 5.9 ns/op > addAll HashSet 100 1864.2 ? 102.4 ns/op > addAll HashSet 1000 16615.5 ? 1202.6 ns/op > collectionsAddAll HashSet 10 172.8 ? 6.0 ns/op > collectionsAddAll HashSet 100 2355.8 ? 195.4 ns/op > collectionsAddAll HashSet 1000 20364.7 ? 1164.0 ns/op > > addAll ArrayDeque 10 54.0 ? 0.4 ns/op > addAll ArrayDeque 100 319.7 ? 2.5 ns/op > addAll ArrayDeque 1000 3176.9 ? 22.2 ns/op > collectionsAddAll ArrayDeque 10 66.5 ? 1.4 ns/op > collectionsAddAll ArrayDeque 100 808.1 ? 55.9 ns/op > collectionsAddAll ArrayDeque 1000 5639.6 ? 240.9 ns/op > > addAll CopyOnWriteArrayList 10 18.0 ? 0.7 ns/op > addAll CopyOnWriteArrayList 100 39.4 ? 1.7 ns/op > addAll CopyOnWriteArrayList 1000 371.1 ? 17.0 ns/op > collectionsAddAll CopyOnWriteArrayList 10 251.9 ? 18.4 ns/op > collectionsAddAll CopyOnWriteArrayList 100 3405.9 ? 304.8 ns/op > collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ? 23502.3 ns/op > > addAll ConcurrentLinkedDeque 10 81.4 ? 2.8 ns/op > addAll ConcurrentLinkedDeque 100 609.1 ? 26.4 ns/op > addAll ConcurrentLinkedDeque 1000 4494.5 ? 219.3 ns/op > collectionsAddAll ConcurrentLinkedDeque 10 189.8 ? 2.5 ns/op > collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ? 62.0 ns/op > collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ? 300.9 ns/op > > addAll:?gc.alloc.rate.norm ArrayList 10 160.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 100 880.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayList 1000 8080.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 10 80.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 100 1400.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayList 1000 15025.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > addAll:?gc.alloc.rate.norm HashSet 1000 48516.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 10 464.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 100 5328.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm HashSet 1000 48516.6 ? 0.1 B/op > > addAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 100 560.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ArrayDeque 1000 4160.5 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 10 112.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 100 1048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ArrayDeque 1000 14929.4 ? 0.0 B/op > > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ? 7.3 B/op > > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ? 0.0 B/op > addAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ? 0.1 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ? 0.0 B/op > collectionsAddAll:?gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ? 0.3 B/op > There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. > > So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into add-all - 8193031: revert implementation change but keep one for JavaDoc - Merge branch 'master' into add-all - Merge remote-tracking branch 'origin/add-all' into add-all - 8193031: add elements in bulk in Collections.addAll() - Merge branch 'master' into add-all - 8193031: add elements in bulk in Collections.addAll() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1764/files - new: https://git.openjdk.java.net/jdk/pull/1764/files/c438d282..9d6dcf3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=03-04 Stats: 148 lines in 16 files changed: 87 ins; 44 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764 PR: https://git.openjdk.java.net/jdk/pull/1764 From github.com+10835776+stsypanov at openjdk.java.net Tue Dec 29 20:43:13 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 29 Dec 2020 20:43:13 GMT Subject: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll In-Reply-To: References: <1fcWoUorgA7FRyhasTd5LnrPmxJJgbuAER_TREaDyss=.6e583297-89a3-428f-b232-56b8e777680f@github.com> Message-ID: <6RChicj79qXOyElF3ipqRMKos8Kuq19bldMvG5Mi39I=.b7896a9b-f52b-45d5-a805-4a577556472c@github.com> On Tue, 29 Dec 2020 10:56:02 GMT, Peter Levart wrote: >> Hint: you could use `java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed` if only this method would allow other types of arrays, not just Object[]... I really don't know why this restriction couldn't be lifted as the captured array is fully encapsulated. > > On a second thought, using `java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed` is not a good idea, since the method expects the passed-in array to be trusted and use of this method in `Collections.addAll(col, array)` would wrap an untrusted array. Surely the resulting List would only be used as an argument to `col.addAll(list)`, but since neither `col` is trusted, it could "steal" the passed-in `list` and use it... > Some other implementation of immutable list array wrapper would be needed here. @plevart hi, I've decided to revert implementation change and keep only the change in JavaDoc because it's performance-related part is often referenced to while being incorrect in most of cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/1764 From info at j-kuhn.de Tue Dec 29 21:17:30 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 29 Dec 2020 22:17:30 +0100 Subject: Is SharedSecrets thread-safe? In-Reply-To: References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> Message-ID: <2b877b6a-441a-7945-5e04-55e7ecd6f0cf@j-kuhn.de> It's a bit more complicated - after all we are talking about the memory model and class loading. There are some shared secrets that can be loaded later (e.g. AWT), when Threads are there. The field is only set in one single place inside the JDK, so we are talking about 3 scenarios: * The class is not yet loaded - the field is null, call ensureClassInitialized - which executes the class initializer on the current thread. A subsequent read of the field must be visible - as actions performed in the thread appear to be sequential for that thread. * The class has been successfully loaded, everything relating to that is visible. * The class is currently initialized by an other thread: * The first load of the field yields null - ensureClassInitialized blocks until the class has been loaded. * The first load yields something different than null. The question now is: can the second load yield the previous value? That is: can a field revert to it's original value? Other fields may not be visible yet (except if they have been frozen). So the big question is: can the second read return null after the first has found it to be a non-null value? After reading the "Double checked locking is broken"[1] declaration again - it says that it does work for primitive values that can't be teared. The problem seems to be that the field of the referenced objects are not yet constructed. The good news: the implementations of the shared secrets don't have fields. The better news: reference assignment also can't be teared. - Johannes [1]: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html On 29-Dec-20 18:53, Hans Boehm wrote: > > > On Tue, Dec 29, 2020 at 5:56 AM Johannes Kuhn > wrote: > > > > Depends on what `initialize()` is. > > > > If it (at least) reads a volatile field, then the compiler can't reorder > > the second read before the first. > > > > - Johannes > I disagree with this claim. I have no idea whether concurrency is > possible here, so it may not matter. See below. > > > > > On 29-Dec-20 14:42, > some-java-user-99206970363698485155 at vodafonemail.de > > > wrote: > > > Hello, > > > the class `jdk.internal.access.SharedSecrets` provides getter > methods which all look similar to this: > > > ``` > > > if (static_field == null) { > > > ? ?initialize(); > > > } > > > return static_field; > > > ``` > > If static_field is not volatile, and set concurrently, then the first > read of static_field may return non-null and the second null, without > initialize() even being executed. The Java memory model does not prevent > reordering of non-volatile reads from the same field (for good reason). > > Even if initialize() is executed and performs a volatile read, this > reasoning doesn't hold. The initial static_field read may be delayed > past the volatile read inside the conditional and hence, at least > theoretically, past the second read. Control dependencies don't order > reads, either in Java, or in modern weakly-ordered architectures with > branch prediction. This doesn't matter if initialize() sets static_field. > > This all assumes that having two threads call initialize() is OK. > > Java code with data races is extremely tricky and rarely correct. > > Hans From brett.okken.os at gmail.com Tue Dec 29 21:33:04 2020 From: brett.okken.os at gmail.com (Brett Okken) Date: Tue, 29 Dec 2020 15:33:04 -0600 Subject: Is SharedSecrets thread-safe? In-Reply-To: <2b877b6a-441a-7945-5e04-55e7ecd6f0cf@j-kuhn.de> References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> <2b877b6a-441a-7945-5e04-55e7ecd6f0cf@j-kuhn.de> Message-ID: What guarantees that if the first read does not see null, the second read will not see null? Sections 4.2 and 4.4 of Aleksey?s ?Close Encounters of the JMM Kind? seem to show that such scenario is possible in face of concurrent setting of non-volatile variable. https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-hb-actual https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-unobserved-sync On Tue, Dec 29, 2020 at 3:17 PM Johannes Kuhn wrote: > It's a bit more complicated - after all we are talking about the memory > model and class loading. > > There are some shared secrets that can be loaded later (e.g. AWT), when > Threads are there. > > The field is only set in one single place inside the JDK, so we are > talking about 3 scenarios: > > * The class is not yet loaded - the field is null, call > ensureClassInitialized - which executes the class initializer on the > current thread. A subsequent read of the field must be visible - as > actions performed in the thread appear to be sequential for that thread. > > * The class has been successfully loaded, everything relating to that is > visible. > > * The class is currently initialized by an other thread: > * The first load of the field yields null - ensureClassInitialized > blocks until the class has been loaded. > * The first load yields something different than null. > The question now is: can the second load yield the previous value? > That is: can a field revert to it's original value? > Other fields may not be visible yet (except if they have been frozen). > So the big question is: can the second read return null after the > first has found it to be a non-null value? > > After reading the "Double checked locking is broken"[1] declaration > again - it says that it does work for primitive values that can't be > teared. The problem seems to be that the field of the referenced objects > are not yet constructed. > > The good news: the implementations of the shared secrets don't have > fields. The better news: reference assignment also can't be teared. > > - Johannes > > [1]: > https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > > On 29-Dec-20 18:53, Hans Boehm wrote: > > > > > > On Tue, Dec 29, 2020 at 5:56 AM Johannes Kuhn > > wrote: > > > > > > Depends on what `initialize()` is. > > > > > > If it (at least) reads a volatile field, then the compiler can't > reorder > > > the second read before the first. > > > > > > - Johannes > > I disagree with this claim. I have no idea whether concurrency is > > possible here, so it may not matter. See below. > > > > > > > > On 29-Dec-20 14:42, > > some-java-user-99206970363698485155 at vodafonemail.de > > > > > wrote: > > > > Hello, > > > > the class `jdk.internal.access.SharedSecrets` provides getter > > methods which all look similar to this: > > > > ``` > > > > if (static_field == null) { > > > > initialize(); > > > > } > > > > return static_field; > > > > ``` > > > > If static_field is not volatile, and set concurrently, then the first > > read of static_field may return non-null and the second null, without > > initialize() even being executed. The Java memory model does not prevent > > reordering of non-volatile reads from the same field (for good reason). > > > > Even if initialize() is executed and performs a volatile read, this > > reasoning doesn't hold. The initial static_field read may be delayed > > past the volatile read inside the conditional and hence, at least > > theoretically, past the second read. Control dependencies don't order > > reads, either in Java, or in modern weakly-ordered architectures with > > branch prediction. This doesn't matter if initialize() sets static_field. > > > > This all assumes that having two threads call initialize() is OK. > > > > Java code with data races is extremely tricky and rarely correct. > > > > Hans > From some-java-user-99206970363698485155 at vodafonemail.de Tue Dec 29 23:32:43 2020 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Wed, 30 Dec 2020 00:32:43 +0100 (CET) Subject: Is SharedSecrets thread-safe? In-Reply-To: References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> Message-ID: <1927632433.243197.1609284763289@mail.vodafone.de> That would also be my understanding of the current situation, though this contradicts what Claes wrote. Maybe the JVM behaves in a way which does not allow reordering, but the JLS definitely seems to allow it. Section ? 12.2.4 [0] only mentions that for the class to be initialized there has to exist a lock LC (or at least the happens-before relationship), but there is no "freeze the world" or anything similar which would force a happens-before relationship for the code in `SharedSecrets`. Maybe most of the `SharedSecrets` methods are thread-safe (albeit extremely brittle) because the classes to which the accessor objects belong to have previously already been loaded before `SharedSecrets` is used, therefore having already established a happens-before relationship. However, this is definitely not the case for all of the methods as shown by the following example: ``` CookieHandler.setDefault(new CookieHandler() { @Override public void put(URI uri, Map> responseHeaders) throws IOException { } @Override public Map> get(URI uri, Map> requestHeaders) throws IOException { return Collections.emptyMap(); } }); // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header) URL url = new URL("https://oracle.com"); url.openConnection().getHeaderFields(); ``` Running this code with `openjdk 15 2020-09-15` shows that the call to `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class `HttpCookie` has been accessed and initialized. Therefore merely running this code in two separate threads (both having been started before the code is executed, since `Thread.start()` establishes a happens-before relationship) should be enough to render that `SharedSecrets` method non-thread-safe. Kind regards [0] https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2 > Hans Boehm hat am 29. Dezember 2020 um 18:53 geschrieben: > > If static_field is not volatile, and set concurrently, then the first read of static_field may return non-null and the second null, without initialize() even being executed. The Java memory model does not prevent reordering of non-volatile reads from the same field (for good reason). > ? > Even if initialize() is executed and performs a volatile read, this reasoning doesn't hold. The initial static_field read may be delayed past the volatile read inside the conditional and hence, at least theoretically, past the second read. Control dependencies don't order reads, either in Java, or in modern weakly-ordered architectures with branch prediction. This doesn't matter if initialize() sets static_field. > ? > This all assumes that having two threads call initialize() is OK. > ? > Java code with data races is extremely tricky and rarely correct. > ? > Hans From claes.redestad at oracle.com Wed Dec 30 00:53:26 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Dec 2020 01:53:26 +0100 Subject: Is SharedSecrets thread-safe? In-Reply-To: <1927632433.243197.1609284763289@mail.vodafone.de> References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> <1927632433.243197.1609284763289@mail.vodafone.de> Message-ID: <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com> Hans' assessment seems about right in the generic case he's describing. But consider: 1. There is no concurrent setting of anything here - it's done in a static initializer which will happen exactly once by the thread initializing the class ($ 12.2.4 item 9). 2. While there is a data race on the access of the fields in SharedSecrets, all of the Access instances are stateless. This means the race is benign in the sense that when reading the field only a null or a safely published instance can be observed. I wouldn't swear there's a strict guarantee a null can never be returned from a SharedSecrets accessor though. Perhaps that's something that could be hardened. /Claes On 2020-12-30 00:32, some-java-user-99206970363698485155 at vodafonemail.de wrote: > That would also be my understanding of the current situation, though this contradicts what > Claes wrote. > Maybe the JVM behaves in a way which does not allow reordering, but the JLS definitely seems > to allow it. Section ? 12.2.4 [0] only mentions that for the class to be initialized there > has to exist a lock LC (or at least the happens-before relationship), but there is no > "freeze the world" or anything similar which would force a happens-before relationship > for the code in `SharedSecrets`. > > Maybe most of the `SharedSecrets` methods are thread-safe (albeit extremely brittle) because > the classes to which the accessor objects belong to have previously already been loaded > before `SharedSecrets` is used, therefore having already established a happens-before > relationship. > However, this is definitely not the case for all of the methods as shown by the following > example: > ``` > CookieHandler.setDefault(new CookieHandler() { > @Override > public void put(URI uri, Map> responseHeaders) throws IOException { } > > @Override > public Map> get(URI uri, Map> requestHeaders) throws IOException { > return Collections.emptyMap(); > } > }); > > // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header) > URL url = new URL("https://oracle.com"); > url.openConnection().getHeaderFields(); > ``` > > Running this code with `openjdk 15 2020-09-15` shows that the call to > `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class `HttpCookie` has > been accessed and initialized. Therefore merely running this code in two separate threads > (both having been started before the code is executed, since `Thread.start()` establishes > a happens-before relationship) should be enough to render that `SharedSecrets` method > non-thread-safe. > > Kind regards > > > [0] https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2 > >> Hans Boehm hat am 29. Dezember 2020 um 18:53 geschrieben: >> >> If static_field is not volatile, and set concurrently, then the first read of static_field may return non-null and the second null, without initialize() even being executed. The Java memory model does not prevent reordering of non-volatile reads from the same field (for good reason). >> >> Even if initialize() is executed and performs a volatile read, this reasoning doesn't hold. The initial static_field read may be delayed past the volatile read inside the conditional and hence, at least theoretically, past the second read. Control dependencies don't order reads, either in Java, or in modern weakly-ordered architectures with branch prediction. This doesn't matter if initialize() sets static_field. >> >> This all assumes that having two threads call initialize() is OK. >> >> Java code with data races is extremely tricky and rarely correct. >> >> Hans From hboehm at google.com Thu Dec 31 01:30:34 2020 From: hboehm at google.com (Hans Boehm) Date: Wed, 30 Dec 2020 17:30:34 -0800 Subject: Is SharedSecrets thread-safe? In-Reply-To: <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com> References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> <1927632433.243197.1609284763289@mail.vodafone.de> <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com> Message-ID: It sounds as though this would be correct if if (static_field == null) { initialize(); } return static_field; ``` were rewritten as Foo my_local_copy = static_field; if (my_copy == null) { initialize(); my_local_copy = static_field; } return my_local_copy; That would prevent the redundant read of static_field unless this thread did the initialization, in which case the original null would no longer be visible to the second read. Hans On Tue, Dec 29, 2020 at 4:55 PM Claes Redestad wrote: > Hans' assessment seems about right in the generic case he's describing. > > But consider: > > 1. There is no concurrent setting of anything here - it's done in a > static initializer which will happen exactly once by the thread > initializing the class ($ 12.2.4 item 9). > > 2. While there is a data race on the access of the fields in > SharedSecrets, all of the Access instances are stateless. This means the > race is benign in the sense that when reading the field only a null or > a safely published instance can be observed. > > I wouldn't swear there's a strict guarantee a null can never be returned > from a SharedSecrets accessor though. Perhaps that's something that > could be hardened. > > /Claes > > On 2020-12-30 00:32, some-java-user-99206970363698485155 at vodafonemail.de > wrote: > > That would also be my understanding of the current situation, though > this contradicts what > > Claes wrote. > > Maybe the JVM behaves in a way which does not allow reordering, but the > JLS definitely seems > > to allow it. Section ? 12.2.4 [0] only mentions that for the class to be > initialized there > > has to exist a lock LC (or at least the happens-before relationship), > but there is no > > "freeze the world" or anything similar which would force a > happens-before relationship > > for the code in `SharedSecrets`. > > > > Maybe most of the `SharedSecrets` methods are thread-safe (albeit > extremely brittle) because > > the classes to which the accessor objects belong to have previously > already been loaded > > before `SharedSecrets` is used, therefore having already established a > happens-before > > relationship. > > However, this is definitely not the case for all of the methods as shown > by the following > > example: > > ``` > > CookieHandler.setDefault(new CookieHandler() { > > @Override > > public void put(URI uri, Map> responseHeaders) > throws IOException { } > > > > @Override > > public Map> get(URI uri, Map List> requestHeaders) throws IOException { > > return Collections.emptyMap(); > > } > > }); > > > > // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header) > > URL url = new URL("https://oracle.com"); > > url.openConnection().getHeaderFields(); > > ``` > > > > Running this code with `openjdk 15 2020-09-15` shows that the call to > > `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class > `HttpCookie` has > > been accessed and initialized. Therefore merely running this code in two > separate threads > > (both having been started before the code is executed, since > `Thread.start()` establishes > > a happens-before relationship) should be enough to render that > `SharedSecrets` method > > non-thread-safe. > > > > Kind regards > > > > > > [0] > https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2 > > > >> Hans Boehm hat am 29. Dezember 2020 um 18:53 > geschrieben: > >> > >> If static_field is not volatile, and set concurrently, then the first > read of static_field may return non-null and the second null, without > initialize() even being executed. The Java memory model does not prevent > reordering of non-volatile reads from the same field (for good reason). > >> > >> Even if initialize() is executed and performs a volatile read, this > reasoning doesn't hold. The initial static_field read may be delayed past > the volatile read inside the conditional and hence, at least theoretically, > past the second read. Control dependencies don't order reads, either in > Java, or in modern weakly-ordered architectures with branch prediction. > This doesn't matter if initialize() sets static_field. > >> > >> This all assumes that having two threads call initialize() is OK. > >> > >> Java code with data races is extremely tricky and rarely correct. > >> > >> Hans > From plevart at openjdk.java.net Thu Dec 31 10:07:05 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 31 Dec 2020 10:07:05 GMT Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets Message-ID: See: https://bugs.openjdk.java.net/browse/JDK-8259021 See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html ------------- Commit messages: - 8259021 avoid double racy reads from non-volatile fields of SharedSecrets Changes: https://git.openjdk.java.net/jdk/pull/1914/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1914&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259021 Stats: 96 lines in 1 file changed: 50 ins; 0 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/1914.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1914/head:pull/1914 PR: https://git.openjdk.java.net/jdk/pull/1914 From peter.levart at gmail.com Thu Dec 31 10:07:32 2020 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 31 Dec 2020 11:07:32 +0100 Subject: Is SharedSecrets thread-safe? In-Reply-To: References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> <1927632433.243197.1609284763289@mail.vodafone.de> <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com> Message-ID: <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com> On 12/31/20 2:30 AM, Hans Boehm wrote: > It sounds as though this would be correct if > > if (static_field == null) { > initialize(); > } > return static_field; > ``` > > were rewritten as > > Foo my_local_copy = static_field; > if (my_copy == null) { > initialize(); > my_local_copy = static_field; > } > return my_local_copy; > > That would prevent the redundant read of static_field unless this thread > did the initialization, in which case the original null would no longer be > visible to the second read. > > Hans I agree. The initialize() part is triggering some class initialization where concurrent attempts do establish a HB edge so the 2nd read of static_field after initialize() is ordered properly and can't read null. I created a JIRA ticket here: https://bugs.openjdk.java.net/browse/JDK-8259021 And prepared a PR here: https://github.com/openjdk/jdk/pull/1914 Happy new year, Peter > > On Tue, Dec 29, 2020 at 4:55 PM Claes Redestad > wrote: > >> Hans' assessment seems about right in the generic case he's describing. >> >> But consider: >> >> 1. There is no concurrent setting of anything here - it's done in a >> static initializer which will happen exactly once by the thread >> initializing the class ($ 12.2.4 item 9). >> >> 2. While there is a data race on the access of the fields in >> SharedSecrets, all of the Access instances are stateless. This means the >> race is benign in the sense that when reading the field only a null or >> a safely published instance can be observed. >> >> I wouldn't swear there's a strict guarantee a null can never be returned >> from a SharedSecrets accessor though. Perhaps that's something that >> could be hardened. >> >> /Claes >> >> On 2020-12-30 00:32, some-java-user-99206970363698485155 at vodafonemail.de >> wrote: >>> That would also be my understanding of the current situation, though >> this contradicts what >>> Claes wrote. >>> Maybe the JVM behaves in a way which does not allow reordering, but the >> JLS definitely seems >>> to allow it. Section ? 12.2.4 [0] only mentions that for the class to be >> initialized there >>> has to exist a lock LC (or at least the happens-before relationship), >> but there is no >>> "freeze the world" or anything similar which would force a >> happens-before relationship >>> for the code in `SharedSecrets`. >>> >>> Maybe most of the `SharedSecrets` methods are thread-safe (albeit >> extremely brittle) because >>> the classes to which the accessor objects belong to have previously >> already been loaded >>> before `SharedSecrets` is used, therefore having already established a >> happens-before >>> relationship. >>> However, this is definitely not the case for all of the methods as shown >> by the following >>> example: >>> ``` >>> CookieHandler.setDefault(new CookieHandler() { >>> @Override >>> public void put(URI uri, Map> responseHeaders) >> throws IOException { } >>> @Override >>> public Map> get(URI uri, Map> List> requestHeaders) throws IOException { >>> return Collections.emptyMap(); >>> } >>> }); >>> >>> // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header) >>> URL url = new URL("https://oracle.com"); >>> url.openConnection().getHeaderFields(); >>> ``` >>> >>> Running this code with `openjdk 15 2020-09-15` shows that the call to >>> `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class >> `HttpCookie` has >>> been accessed and initialized. Therefore merely running this code in two >> separate threads >>> (both having been started before the code is executed, since >> `Thread.start()` establishes >>> a happens-before relationship) should be enough to render that >> `SharedSecrets` method >>> non-thread-safe. >>> >>> Kind regards >>> >>> >>> [0] >> https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2 >>>> Hans Boehm hat am 29. Dezember 2020 um 18:53 >> geschrieben: >>>> If static_field is not volatile, and set concurrently, then the first >> read of static_field may return non-null and the second null, without >> initialize() even being executed. The Java memory model does not prevent >> reordering of non-volatile reads from the same field (for good reason). >>>> Even if initialize() is executed and performs a volatile read, this >> reasoning doesn't hold. The initial static_field read may be delayed past >> the volatile read inside the conditional and hence, at least theoretically, >> past the second read. Control dependencies don't order reads, either in >> Java, or in modern weakly-ordered architectures with branch prediction. >> This doesn't matter if initialize() sets static_field. >>>> This all assumes that having two threads call initialize() is OK. >>>> >>>> Java code with data races is extremely tricky and rarely correct. >>>> >>>> Hans From github.com+471021+marschall at openjdk.java.net Thu Dec 31 10:15:12 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Thu, 31 Dec 2020 10:15:12 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) In-Reply-To: References: Message-ID: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com> On Thu, 31 Dec 2020 10:10:56 GMT, Philippe Marschall wrote: > Implement three optimiztations for Reader.read(CharBuffer) > > * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. > * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. > * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. > * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. A couple of implementation notes: Reader#read(CharBuffer) on-heap case I introduced a dedicated path for the on-heap case and directly read into the backing array. This completely avoids the intermediate allocation and copy. Compared to the initial proposal the buffer position is updated. This has to be done because we bypass the buffer and directly read into the array. This also handles the case that #read returns -1. I am using a c-style array declaration because the rest of the class uses it. off-heap case I limit the intermadiate allocation to TRANSFER_BUFFER_SIZE. In order to reduce the total intermediate allocation we now call #read multiple times until the buffer is full or EOF is reached. This changes the behavior slightly as now possibly more data is read. However this should contribute to reduce the overall intermediate allocations. A lock is acquired to keep the the read atomic. This is consistent with #skip which also holds a lock over multiple #read calls. This is inconsistent with #transferTo which does not acquire a lock over multiple #read calls. The implementation took inspiration from java.io.InputStream#readNBytes(int). InputStreamReader#read(CharBuffer) Since StreamDecoder is a Reader as well we can simply delegate. StreamDecoder#read(CharBuffer) Interestingly this was not implemented even though StreamDecoder internally works on NIO buffers. on-heap case We see a performance improvement and the elimination of all intermediate allocation. StreamDecoder#read(char[], int, int) and InputStreamReader#read(char[], int, int) may get a small improvement as we no longer #slice the buffer. off-heap case We see the elimination of all intermediate allocation but a performance penalty because we hit the slow path in #decodeLoop. There is a trade-off here, we could improve the performance to previous levels by introducing intermediate allocation again. I don't know how much the users of off-heap buffers care about introducing intermediate allocation vs maximum throughput. I was struggling to come up with microbenchmarks because the built in InputStream and Reader implementations are finite but JMH calls the benchmark methods repeatably. I ended up implementing custom infinite InputStream and Reader implementations. The code can be found there: https://github.com/marschall/reader-benchmarks/tree/master/src/main/java/com/github/marschall/readerbenchmarks An Excel with charts can be found here: https://github.com/marschall/reader-benchmarks/raw/master/src/main/resources/4926314.xlsx I looked for java.io.Reader#read(CharBuffer) users in the JDK and only found java.util.Scanner#readInput(). I wrote a microbenchmark for this but only found minuscule improvements due to regex dominating the runtime. There seem to be no direct Reader tests in the tier1 suite, the initial code was wrong because I forgot to update the buffer code position but I only found out because some Scanner tests failed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Thu Dec 31 10:15:12 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Thu, 31 Dec 2020 10:15:12 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) Message-ID: Implement three optimiztations for Reader.read(CharBuffer) * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. ------------- Commit messages: - 4926314: Optimize Reader.read(CharBuffer) Changes: https://git.openjdk.java.net/jdk/pull/1915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4926314 Stats: 101 lines in 3 files changed: 68 ins; 8 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915 From some-java-user-99206970363698485155 at vodafonemail.de Thu Dec 31 17:25:45 2020 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Thu, 31 Dec 2020 18:25:45 +0100 (CET) Subject: Is SharedSecrets thread-safe? In-Reply-To: <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com> References: <938640011.238938.1609249350345@mail.vodafone.de> <99d009fe-8901-d107-0779-c8965dfb257b@j-kuhn.de> <1927632433.243197.1609284763289@mail.vodafone.de> <9863a935-29ab-4426-2aa1-75ef0808de41@oracle.com> <0de44a07-cbf3-9924-c667-2e624728e84e@gmail.com> Message-ID: <1114179516.261393.1609435545716@mail.vodafone.de> Hello Peter, the changes look good, however there might be more to consider: - `jdk.internal.access.SharedSecrets.getJavaLangRefAccess()` Might be good to add a comment there or for `java.lang.ref.Reference` that it is (hopefully?) initialized during JVM start-up. Similar to the comment for `AccessibleObject` which states that it is initialized in "initPhase1". Currently without special knowledge about JVM start-up, it is not obvious that this construct is safe. - `java.io.Console.cons` This is pretty brittle. It is currently only thread-safe because the only accessor is `System.console()` which has its own synchronization. However, I doubt that the author was aware that `Console.cons` on its own is not thread-safe. In general, why is there lazy initialization twice? Once in `System.console()` and then in the accessor for `Console.cons`. In my opinion *only* `java.io.Console` should have the lazy initialization logic (with proper synchronization!) and make sure that only one `Console` instance exists. - `jdk.internal.access.JavaIOAccess.charset()` The implementation of this one is extremely brittle. While it documents that the `Password` class calling it will make sure that `System.console()` has been called before, in that `Password` class there is not such notice, so it could easily happen that someone breaks this at a later point. Additionally the field `Console.cs` it accesses is not `final`, making it even more brittle. In my opinion there should be two changes: 1. Change `JavaIOAccess.charset()` -> `charset(Console)`, which then accesses the charset from that Console argument. This enforces that the user of the access already has the Console initialized and indirectly establishes the happens-before relationship for `Console.cs`. 2. The Console class should have the following fields `final`: readLock, writeLock, reader, out, pw, formatter, cs For `cs` this would merely require introducing a local variable. In general `sun.security.util.Password.convertToBytes(char[])` is problematic because it makes passwords unportable when one OS uses a different terminal encoding than another. The cleaner backward compatible solution might be to simply block all non-ASCII chars (i.e. throw exception for them)? This would break for all existing users which used non-ASCII chars or where their terminal has an encoding not based on ASCII, but these users might already have different problems due to the existing implementation. - `jdk.internal.access.SharedSecrets.setJavaAWTAccess(JavaAWTAccess)` Might have to establish a happens-before relationship for `getJavaAWTAccess()` because caller appears to expect a `JavaAWTAccess` in case respective class has been loaded. On a side note here: The implementation of that access appears to contain redundant code: https://github.com/openjdk/jdk/blob/8435f0daf2413a4c17578dd288e093fe006b3880/src/java.desktop/share/classes/sun/awt/AppContext.java#L866 The null check there makes no sense because `ecx` is always null at that point. - `jdk.internal.access.SharedSecrets.setJavaAWTFontAccess(JavaAWTFontAccess)` This seems to be rather brittle as well because its callers check whether the access has already been initialized. Additionally this seems to be more complicated than it has to be: It appears to be simpler to have `SharedSecrets` initialize the access by initializing only `NumericShaper` (or `TextAttribute`, ultimately does not matter which class from that package is used) when `getJavaAWTFontAccess()` is called. The performance penalty (if any) is likely negligible. - `com.sun.jmx.mbeanserver.JavaBeansAccessor` Since the static initializer of that class is loading `Introspector` (which sets access object) anyways it might be saner to have this initialization logic in `SharedSecrets` instead. Kind regards > Peter Levart hat am 31. Dezember 2020 um 11:07 geschrieben: > > > > On 12/31/20 2:30 AM, Hans Boehm wrote: > > It sounds as though this would be correct if > > > > if (static_field == null) { > > initialize(); > > } > > return static_field; > > ``` > > > > were rewritten as > > > > Foo my_local_copy = static_field; > > if (my_copy == null) { > > initialize(); > > my_local_copy = static_field; > > } > > return my_local_copy; > > > > That would prevent the redundant read of static_field unless this thread > > did the initialization, in which case the original null would no longer be > > visible to the second read. > > > > Hans > > > I agree. The initialize() part is triggering some class initialization > where concurrent attempts do establish a HB edge so the 2nd read of > static_field after initialize() is ordered properly and can't read null. > > I created a JIRA ticket here: > https://bugs.openjdk.java.net/browse/JDK-8259021 > > And prepared a PR here: https://github.com/openjdk/jdk/pull/1914 > > > Happy new year, > > Peter > > > > > > On Tue, Dec 29, 2020 at 4:55 PM Claes Redestad > > wrote: > > > >> Hans' assessment seems about right in the generic case he's describing. > >> > >> But consider: > >> > >> 1. There is no concurrent setting of anything here - it's done in a > >> static initializer which will happen exactly once by the thread > >> initializing the class ($ 12.2.4 item 9). > >> > >> 2. While there is a data race on the access of the fields in > >> SharedSecrets, all of the Access instances are stateless. This means the > >> race is benign in the sense that when reading the field only a null or > >> a safely published instance can be observed. > >> > >> I wouldn't swear there's a strict guarantee a null can never be returned > >> from a SharedSecrets accessor though. Perhaps that's something that > >> could be hardened. > >> > >> /Claes > >> > >> On 2020-12-30 00:32, some-java-user-99206970363698485155 at vodafonemail.de > >> wrote: > >>> That would also be my understanding of the current situation, though > >> this contradicts what > >>> Claes wrote. > >>> Maybe the JVM behaves in a way which does not allow reordering, but the > >> JLS definitely seems > >>> to allow it. Section ? 12.2.4 [0] only mentions that for the class to be > >> initialized there > >>> has to exist a lock LC (or at least the happens-before relationship), > >> but there is no > >>> "freeze the world" or anything similar which would force a > >> happens-before relationship > >>> for the code in `SharedSecrets`. > >>> > >>> Maybe most of the `SharedSecrets` methods are thread-safe (albeit > >> extremely brittle) because > >>> the classes to which the accessor objects belong to have previously > >> already been loaded > >>> before `SharedSecrets` is used, therefore having already established a > >> happens-before > >>> relationship. > >>> However, this is definitely not the case for all of the methods as shown > >> by the following > >>> example: > >>> ``` > >>> CookieHandler.setDefault(new CookieHandler() { > >>> @Override > >>> public void put(URI uri, Map> responseHeaders) > >> throws IOException { } > >>> @Override > >>> public Map> get(URI uri, Map >> List> requestHeaders) throws IOException { > >>> return Collections.emptyMap(); > >>> } > >>> }); > >>> > >>> // Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header) > >>> URL url = new URL("https://oracle.com"); > >>> url.openConnection().getHeaderFields(); > >>> ``` > >>> > >>> Running this code with `openjdk 15 2020-09-15` shows that the call to > >>> `SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class > >> `HttpCookie` has > >>> been accessed and initialized. Therefore merely running this code in two > >> separate threads > >>> (both having been started before the code is executed, since > >> `Thread.start()` establishes > >>> a happens-before relationship) should be enough to render that > >> `SharedSecrets` method > >>> non-thread-safe. > >>> > >>> Kind regards > >>> > >>> > >>> [0] > >> https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2 > >>>> Hans Boehm hat am 29. Dezember 2020 um 18:53 > >> geschrieben: > >>>> If static_field is not volatile, and set concurrently, then the first > >> read of static_field may return non-null and the second null, without > >> initialize() even being executed. The Java memory model does not prevent > >> reordering of non-volatile reads from the same field (for good reason). > >>>> Even if initialize() is executed and performs a volatile read, this > >> reasoning doesn't hold. The initial static_field read may be delayed past > >> the volatile read inside the conditional and hence, at least theoretically, > >> past the second read. Control dependencies don't order reads, either in > >> Java, or in modern weakly-ordered architectures with branch prediction. > >> This doesn't matter if initialize() sets static_field. > >>>> This all assumes that having two threads call initialize() is OK. > >>>> > >>>> Java code with data races is extremely tricky and rarely correct. > >>>> > >>>> Hans